On Fri, 23 Apr 2010 18:34:56 EDT erik quanstrom <quans...@labs.coraid.com> wrote: > > On Fri, Apr 23, 2010 at 1:08 PM, Bakul Shah <bakul+pl...@bitblocks.com> wro > te: > > > > > > > > If so, I consider it a bug; particularly as there is no > > > overflow involved anywhere. > > > > > > > > > > r1 2147482110 r2 -1537 > > on arm the difference is interesting. the first > / is translated: > main+0x20 0x00001040 MOVW (R4>>1),R4 > and the second: > main+0x34 0x00001054 ADD.MI $#0x1,R2,R2 > main+0x38 0x00001058 MOVW (R2->1),R2 > > (5c -S has it SRL and SRA, respectively.) > if we are unsigned preserving, wouldn't this make sense, since > (x + y + z) is an unsigned expression but (x + y) is not.
It is clear that there is no one *right* answer for how mixed signed/unsigned number operations should be treated but c89 rules do seem a bit more sensible to me as they avoid surprises like (x + y + 0u)/z being different from (x + y)/z, where x,y,z are signed ints. Is this behaviour really useful for anything? Is there anything in plan9 code that relies on this behaviour in a critical way? I suspect this rule can be changed without impacting plan 9 code much (which as a rule is of much higher quality than most open source code) and we already know programs ported to p9p work fine. Anyway, I think I've said all I want to on this topic! Probably more than.
