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

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2011 Jasper Spaans