Messages in this thread |  | | | Date | Tue, 18 Jan 2000 17:46:41 +0100 | | From | Jamie Lokier <> | | Subject | Re: Recent change in tcp_output.c is surely wrong |
| |
Richard B. Johnson wrote: > > 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'. > > I don't think so.
Correct, the first paragraph above is a thinko. Please see followup where I retract it.
> Here, we start with a 1 and shift it over into the > sign-bit. It now becomes the highest negative number. Now, we shift > it back exactly the same number of bits. See that the sign-bits are > __extended__! It now becomes -1.
Now you're thinking about GCC, not the ISO C standard. In ISO C, sign bits don't exist (not every machine does signed arithmetic with 2's complement -- rounded floating point is possible for example), and the shift you described leads to undefined behaviour.
Even real compilers don't always sign extend signed right shifts.
> This is because 'C' treats shifts as arithmetic shifts, not logical > shifts. The code is (for Intel) sar and sal, not shr and shl. You > cannot reliably use shifts for ANDing operations if you are writing > in 'C'.
GCC and probably most C compilers do that but it is not guaranteed by C in general. Maybe all known x86 compilers use sar. However, I am sure there have been C compilers that donn't use arithmetic shifts. If only I could remember which ones :-)
-- 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/
|  |