Subject: Re: lib/16518 (some fixes to libpcap)
To: YAMAMOTO Takashi <email@example.com>
From: Matthias Drochner <M.Drochner@fz-juelich.de>
Date: 02/25/2006 16:16:27
> portability thing? iirc, it was for correct operations, not for
OK, I see that there is another case where the signed/unsigned
makes a difference: division.
So you are right, it is not just about the ">>" portability.
Well, the documentation isn't clear in this respect:
At one point it says:
P[i:n] gives the data at byte offset
``i'' in the packet, interpreted as a word (n=4), unsigned halfword (n=2),
or unsigned byte (n=1).
The halfword and byte are explicitely unsigned, the "word" not.
This might however not refer to arithmetics but just to the fact
that no sign extension happens when a shorter value is loaded
into the accumulator.
There is also the BPF_NEG which wouldn't make much sense in a
strictly unsigned world.
Otoh, since the kernel does unsigned arithmetics and has always
done, I'd definitely expect that the userland filter behaves
I somehow believe that almost noone does arithmetics on values
which use up the 32 bits, let alone division. That's why
noone really cares...