[lkml]   [2000]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.019 / U:6.908 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site