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:
- net net/len (0.0.0.0) Felipe Kellermann (May 27)
- Re: net net/len (0.0.0.0) Felipe Kellermann (May 27)
- Re: net net/len (0.0.0.0) Felipe Kellermann (May 28)
- Re: net net/len (0.0.0.0) Guy Harris (May 28)
- Re: net net/len (0.0.0.0) Felipe Kellermann (May 28)
- Re: net net/len (0.0.0.0) Guy Harris (May 28)
- Re: net net/len (0.0.0.0) Felipe Kellermann (May 27)