Messages in this thread | | | Date | Tue, 18 Jan 2000 11:10:26 +0100 | From | Jamie Lokier <> | Subject | Re: Recent change in tcp_output.c is surely wrong |
| |
Rogier Wolff wrote: > On the other hand, having thousands "silent departures from ANSI-C" > scattered through the kernel is not a good idea. I'm fine with having > a few __asm__ thingies that generate errors while compiling/linking. > > Someone is eventually going to have to port Linux to an architecture > that doesn't have a gcc port yet.
It breaks with GCC too. How obvious do I have to be?
#include <stdio.h> int main () { unsigned short a = 0xffff; a = (a << 1) >> 1; printf ("a = 0x%x\n", (unsigned) a); return 0; }
$ gcc -o test test.c $ ./test a = 0xffff
--> high bit /not/ cleared
> Oh, by the way, ANSI defines the behaviour as undefined, as a compiler > is allowed to recognize that (var <<1) >> 1 evaluates to "var" if done > with arbitrary precision.
No. For any unsigned type as wide or wider than `unsigned int', that will clear the top bits. For narrower unsigned types it won't. For signed types it is implementation defined.
> for example > > array [index>>4].firstbyte = 0; > > could evaluate (the element size of array happens to be 16 bytes!) > > * (char *)array + (index & ~0xf) = 0; > > See, the compiler recognized that two shifts over the same width are > the same.
Your example is wrong. You've shown `(a >> 4) << 4', which is obviously equal to `a & ~0xf' for any type :-)
-- 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/
| |