lkml.org 
[lkml]   [2000]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.038 / U:24.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site