Subject: Re: lib/16518 (some fixes to libpcap)
To: None <,,>
From: YAMAMOTO Takashi <>
List: netbsd-bugs
Date: 02/25/2006 15:50:02
The following reply was made to PR lib/16518; it has been noted by GNATS.

From: YAMAMOTO Takashi <>
Subject: Re: lib/16518 (some fixes to libpcap) 
Date: Sun, 26 Feb 2006 00:47:39 +0900

 > 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 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.