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
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/

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