Subject: Re: lib/16518 (some fixes to libpcap)
To: None <lib-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: netbsd-bugs
Date: 02/27/2006 23:20:02
The following reply was made to PR lib/16518; it has been noted by GNATS.

From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: M.Drochner@fz-juelich.de
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: Tue, 28 Feb 2006 08:18:45 +0900

 > yamt@mwd.biglobe.ne.jp said:
 > > was not sure which of signed or unsigned should be used.
 > 
 > For me it is pretty obvious that unsigned should be used,
 > to be consistent with kernel behaviour. While the manpage
 > doesn't tell, the kernel implementations are there and
 > cannot be changed anymore, just documented.
 
 to be consistent with kernel, yes.  i thought so and made the patch.
 i still support the "fix libpcap optimizer to match to kernel" way.
 
 but if it's considered a kernel bug, we can fix kernel implementations, IMO.
 see below.
 
 > Optimization of "=" gets a bit further -- a call of
 > tcpdump "(0x80000000 / 2) = 0x40000000"
 > does yield
 > tcpdump: expression rejects all packets
 > while
 > tcpdump -O "(0x80000000 / 2) = 0x40000000"
 > happily receives packets.
 > 
 > Your patch fixes exactly these inconsistencies.
 
 sure.
 
 but, if it was "(-10)/2 == -5", one might think it's natural to
 optimize it to TRUE, and consider it as a kernel bug.
 given the lack of strict specification of the language, i couldn't say
 which was correct.
 
 > > i guess it's better to bring a discussion on tcpdump-workers again
 > 
 > This might be a good idea. Do you want to defent your patch once more?
 
 honestly speaking, i don't, as my memory about libpcap and
 the patch is somewhat stale...  i'm happy if you just beat me. :-)
 
 > I'm just working on an update of NetBSD's libpcap to 0.9.4, and I plan
 > to post the more essential changes to tcpdump-workers too.
 > (Which is merely some "const" consistency for now, and support for
 > the cloning /dev/bpf.)
 
 great.
 
 YAMAMOTO Takashi