Messages in this thread | | | Date | Tue, 18 Jan 2000 12:50:03 +0100 | From | Jamie Lokier <> | Subject | Re: Recent change in tcp_output.c is surely wrong |
| |
Jamie Lokier wrote: > Rogier Wolff wrote: > > (a << 4) >> 4 > > > > Usually, ANSI will take the road where the compiler writer is allowed > > to optimize for the common case: More accuracy usually doesn't matter. > > For a signed int, that optimisation would be valid on an Alpha. Even in > GCC's model. Think about what signed right shifts do. But for an > unsigned int, it would be equivalent to `a & 0x0fffffff'.
Oops, I'm being dense here.
For unsigned int, the compiler may write `a & 0x0fffffff'. The standard is precise. It talks about powers of two and modulo arithmetic.
For signed int, the compiler also has that option: Non-negative signed values less than a certain value as left shifted and right shifted just as the unsigned quantities. For left shift, negative values and values large enough to overflow after shifting gives undefined behaviour. (E.g. an overflow trap is possible) For right shift, negative values gives implementation defined behaviour.
For the case that started this thread, the behaviour is well defined on all ISO C compilers, and even more so with GCC. When `u32' is narrower than `unsigned int', the top bit is not cleared, otherwise it is.
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |