tcpdump mailing list archives

Re: net net/len (0.0.0.0)


From: "Guy Harris" <guy () alum mit edu>
Date: Sun, 28 May 2006 13:14:14 -0700 (PDT)

Felipe Kellermann wrote:

This fixes the problem to me. Does anyone know why 0xffffffff << (32 - 0)
is resulting in 0xffffffff in mcode?

To quote the ANSI C89 standard, section 3.3.7 "Bitwise Shift Operators":

    If the value of the right operand is negative or is greater than or
equal to the width in bits of the promoted left operand, the behavior
is undefined.

This was done, I think, because some processors' shift instructions take
the shift count modulo the register length, so shifting left by 32 on a
32-bit processor leaves the result unchanged, and other processors' shift
instructions don't, so a shift count of 32 on a 32-bit processor clears
the result.  On 64-bit processors, there might be an additional issue of
64-bit shift instructions, which would presumably, when used to shift a
32-bit quantity, clear the result (as the lower 32 bits would be shifted
into the upper 64 bits, and 32 bits of 0 shifted in) vs. 32-bit shift
instructions, if the processor has them, which might take the shift count
modulo 32.

The OS X machine you tried has a PowerPC processor, which might handle
this differently from x86.  The compiler used could also make a
difference.

The fix is to have gen_mcode() check for a masklen of 0, and explicitly
set m to zero in that case.  I've checked that fix into the main and x.9
branches.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Current thread: