The following reply was made to PR lib/16518; it has been noted by GNATS.

From: Matthias Drochner <M.Drochner@fz-juelich.de>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@NetBSD.org, lib-bug-people@NetBSD.org,
	netbsd-bugs@NetBSD.org, gnats-admin@NetBSD.org
Subject: Re: lib/16518 (some fixes to libpcap) 
Date: Sat, 25 Feb 2006 16:16:27 +0100

 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...
 
 best regards
 Matthias