Daved S. Miller wrote:
>> - If tp->ato has bit 31 set, then the effect depends on the width of `int'.
>> (Because all arithmetic operations in C extend to `int' width first).
>Not true, ato is a u32 and I just double checked that the computation
>is kept unsigned by the compiler on both sparc64 and ix86.
The problem is not signedness. It's to do with arithmetic operand
promotion, which doesn't show up on a machine with 32 bit ints.
Andi Kleen wrote:
> I think "everybody" knew that, the original poster just pointed out that
> the shift trick exploited undefined behaviour in ANSI-C, which is rather
> irrelevant because the Linux kernel is not writen in ANSI-C.
It has undefined behaviour on GCC on any machine where `unsigned int' is
64 bits. Despite `u32' being 32 bits wide.
That's because in C, arithmetic operations on `unsigned short' and
`unsigned char' first extend both arguments to `unsigned int', then do
the operation, then possibly truncate the result if it's being stored
again.
I've tripped over bugs due to that before. I know better now :-)
I don't know if the same rule applies to `unsigned int __attribute__
((mode (HI)))' but I'm absolutely sure I wouldn't like to depend on that!
have a nice day,
-- 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/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:17 EST