the previous patch broke 64-bit ops as the type for the
operation is determined from the first argument to
gopcode() (nod1.type), not the type the result (nod.type).
so we need to include the conversion of nod1 type to
the type of nod.
the bug can be reproduced with the following test case:
#include <u.h>
#include <libc.h>
void
main()
{
int size = 1;
size*=1.5;
exits(0);
}
this produces the following assembly:
TEXT main+0(SB),0,$16
MOVW $1,R1
FCVTZSDW $1.50000000000000000e+00,R2 <- tries to convert rhs to int??
MULW R2,R1,R2 <- multiplication done in int? bug!
MOV $0,R0
BL ,exits+0(SB)
RETURN ,
END ,
the confusion comes from the *= operation using the wrong type
for the multiplication. in this case we should use the float
type of the rhs, do the operation, and then convert the result
back to int type of the lhs.
this change ports the same logic from 5c's getasop().
Characters greater than 0X80 will cause a read beyond the bounds of the
array chars[]. For particular unicode characters this can cause deroff
to segfault.
A minimal example:
$ deroff
.EQ
u∈
Segmentation fault
Throughout deroff, charclass() is used instead of directly indexing
chars[] so I presume this was just missed.
version(5) says:
If the server does not understand the client's version
string, it should respond with an Rversion message (not
Rerror) with the version string the 7 characters
``unknown''.
Pre-lib9p file servers -- all except cwfs(4) -- do return Rerror.
lib9p(2) follows the above spec, although ignoring the next part
concerning comparison after period-stripping. It assumes an
Fcall.version starting with "9P" is correctly formed and returns
the only supported version of the protocol, which seems alright.
This patch brings pre-lib9p servers in accordance with the spec.
The current logging prints a debug line for every
message in an inbox, which is unusably verbose.
This removes the prints for unchanged messages,
and adds a print for flag changes.
The $SCRIPTS were added to $TARG, which complicates the all rule, as
each script's object file must be suppressed.
Fix by removing $SCRIPTS from $TARG, removing the script object file
suppression rule, and overriding the install rule.
The script bin install rule assumes that only one script install is
called at a time. Valid calls like 'mk -a /$objtype/replica/changes
/$objtype/replica/pull' will fail.
Fix by adding a for loop.
Remove the unused $UPDATE variable.
to reproduce:
ipnet=foo0 ip=192.168.0.0 ipmask=/16
ipnet=foo1 ip=192.168.0.0 ipmask=/24
ip=192.168.0.1 sys=foo2
% ndb/ipquery sys foo2 ipnet ipmask
ipnet=foo0 ipmask=/16
we would expect to get ipnet=foo1 here as it is more
specific subnet.
the solution is to order the subnets by prefix length
in subnet() before calling filter(), so that we process
the longest prefixes first.
ape cp, mv, and cc build with ?c, not pcc
ape cp and mv just ignore one or two extra flags,
instead of providing posix compatibility
it's better to fail then do nothing
remove cp.c and mv.c
move cc.c to /sys/src/ape/9src so it doesn't
need its own mkfile rule
we have to disable interrupts during mmuwalk() of user pages
as we can get preempted during mmu walk and the original
m->pml4 might become one of a different process.
Handle cases where parameterless macros expand to each other:
#define FOO BAR
#define BAR FOO
FOO
There were cases where the macros didn't make it into the hidesets,
and we would recurse infinitely. This fixes that.
This change makes it mandatory for programs to call segflush() on
code that is not in the text segment if they want to execute it.
As a side effect, this means that everything but the text segment
will be non-executable by default, even without the SG_NOEXEC
attribute. Segments with the SG_NOEXEC attribute never become
executable, even when segflush() is called on them.
when wstating a file, its directory should be updated to
reflect this change.
here is what the manpage states:
> The mtime field reflects the time of the last change of content
> (except when later changed by wstat). For a directory it is the
> time of the most recent remove, create, or wstat of a file in the
> directory.
when wstating a file, its directory should be updated to
reflect this change.
here is what the manpage states:
> The mtime field reflects the time of the last change of content
> (except when later changed by wstat). For a directory it is the
> time of the most recent remove, create, or wstat of a file in the
> directory.
When calling putc, we need to return either EOF
or the character returned. To distinguish the
two, we need to avoid sign extending 0xff. The
code attempted to do this, but the order of
operations was wrong, so we ended up masking,
setting a character, and then sign extending
the character.
This fixes things so we mask after assignment.
For big mailboxes with imap4d, ignoring the index and trying to scan
the mailbox concurrently is not very productive. Just wait for the
other upas/fs to write the whole index.
The issue is that imap might time out and make another connection
spawning even more upas/fs instances that all then try to rebuild
the index concurrently.
this breaks interrupt key handling in rio. theres also no
point in trying todo so as rio sends the note to the whole
process group so the subcommand should have got the note
already.
just wait for the subprocess to terminate.
the date, from and replyto fields where unstable, in that the value
read depended on the state of the cache.
fixing the from and replyto fields is easy, we just handle the
substitution in parsebody().
the date field however requires us to put the date822 into the index
so it can be recovered without requiering to reparse the header
(and body, as we might have a message/rfc822 message with promoted
fields).
with these changes, the fields will be consistent and independnet
of the cache state.
a small optimization also has been added:
after parsing the body, attachments and substitution of from/replyto,
the boundary and unixfrom strings are not needed anymore and can
be freed early.
When read() failed, we were casting the -1 return to
unsigned, which would cause us to index out of bounds.
found using dovecot imap test suite. While we're here,
let's remove the stray debug prints.
widen and move the KMAP window to a new address so we can
handle the 8GB of physical memory of the new raspberry pi4.
the new memory map on pi4 uses the following 4 banks:
0x000000000 0x03e600000
0x040000000 0x0fc000000 <- soc.dramsize (only < 4GB)
0x100000000 0x180000000
0x180000000 0x200000000
