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

From: Matthias Drochner <>
To: YAMAMOTO Takashi <>
Subject: Re: lib/16518 (some fixes to libpcap) 
Date: Sat, 25 Feb 2006 16:16:27 +0100 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
 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...
 best regards