I agree, this is not the true root of the problem, merely a symptom fix. However, reverting to break statements preserves all of the fixes provided in Yamamoto's patch, and makes the examples I provided work properly.
A similar case that is still not handled properly is: tcpdump 'len=len' is always true tcpdump 'len=0 or len=len' should also be true, but fails thusly: (000) ld #pktlen (001) jeq #0x0 jt 3 jf 2 (002) jeq x jt 3 jf 4 (003) ret #68 (004) ret #0 When I compile without any peep ahead, it behaves properly in all cases. :-p I'll keep working on the optimizer, but suggest using the patch I supplied for the time being, to get rid of most of the problem if this is to be released. Is there a standard set of filters, as well as a data file & result set for compile & optimize regression testing? g On Wed, 17 Dec 2003 10:04:39 -0800 Guy Harris <[EMAIL PROTECTED]> wrote: > I've been looking at this - there is, I think, an optimizer bug > elsewhere, and his change might merely have exposed that bug. I haven't > tracked it down yet, however. (It's converting the "false" branch of > one jeq to go to the "ret #0" when it shouldn't be. This might also be > the cause of a bug in the libpcap bug database on SourceForge.) > > His changes fix some other problems: > > Date: Thu, 25 Apr 2002 07:20:47 +0900 (JST) > To: [EMAIL PROTECTED] > Subject: some fixes for complier and optimizer in libpcap > From: YAMAMOTO Takashi <[EMAIL PROTECTED]> > > I made patches for libpcap. > > it includes: > - make tcpdump "1 > 1" works correctly. > - make things unsigned as in-kernel filter does. > - fix a bug that prevents optimization. (and might cause bad codes) > eg. "1 & len == 1" > - fix wrong optimizations. > eg. "0 >> len == 1", "0 - len == 1" -- George Bakos Institute for Security Technology Studies - IRIA Dartmouth College [EMAIL PROTECTED] 603.646.0665 -voice 603.646.0666 -fax - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
