> yamt@mwd.biglobe.ne.jp said:
> > portability thing? iirc, it was for correct operations, not for
> > portability. 
> 
> 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
> identically.
> 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...

yea, the fundamental problem is that the definition of filter program
language is somewhat vague about signedness.  the part of patch was
dropped because the tcpdump.org guy who handled the patch (itojun)
was not sure which of signed or unsigned should be used.
(see "Re: some fixes for complier and optimizer in libpcap" mails
on tcpdump-workers around June 2002)

i guess it's better to bring a discussion on tcpdump-workers again
and try to fix the problem in their repository first, rather than just
being different from their version.

YAMAMOTO Takashi