Hi, Well, still not that warm fuzzy feeling about it. I'll give you something to think about.
The whole discussion focuses on the use of the != operator, which is the NE operator. We'll need to consider that the same discussion can be held for the LT, LE, GT and GE operators. Imagine this storyline: "I want only the packets with addresses not in my managment lan, so above 10.1.255.255. When I use ip.addr > 10.1.255.255 I still get packets from and to my management LAN". Basically the same problem here, although not reported (and probably not encountered) as frequently. Another thing is that dfilter expressions become a dialect depending on the place (Wireshark configuration file instance) it runs. That is between different users, but also between configuration file sets, as were recently introduced. May I offer a different proposal, based on a former colleague's bug solving method. Since we have two (three actually) ways of expressing Not Equal, being "!(...)" and ".. != .." and ".. NE ..", why not drop support for the ".. != .." (and ".. NE ..") ? This solution has the following advantages: * It removes code i.s.o. adding hooks in the grammer.lemon or semcheck.c or where ever this warning comes from. * It shifts the use of the unwanted ".. != .." aways to the desired "!(..)". * The syntax (error) becomes apparent when editing the expression, not when applying it. * We could even keep ".. NE .." around for the power users. This solution has the following disadvantages: * It drops an operator where people are used to. * Display filter generators may need to be changed * Color display filters may become invalid. Thanx, Jaap Sake Blok wrote: > On Tue, Jan 29, 2008 at 10:05:27AM +0900, Kenichi Okuyama wrote: >> Sorry to interrupt you. I simply want to make sure. You mean, in >> current implementation: >> >> a) ( ip.addr == 1.2.3.4 ) means (( ip.src == 1.2.3.4 )||( ip.dst == 1.2.3.4 >> )). >> >> b) ( ip.addr != 1.2.3.4 ) means (( ip.src != 1.2.3.4 )||( ip.dst != 1.2.3.4 >> )) >> which stands for !(( ip.src == 1.2.3.4 )&&( ip.dst == 1.2.3.4 )) >> ( which means "ignore if both src and dst are 1.2.3.4" ) >> >> c) !ip.addr == 1.2.3.4 means ( !( ip.addr == 1.2.3.4 )) >> which stands for ( !(( ip.src == 1.2.3.4 )||( ip.dst == 1.2.3.4 ))) >> which stands for ( ip.src != 1.2.3.4 )&&( ip.dst != 1.2.3.4 ) > > Yes, a, b and c are correct. > >> I do agree about b) being very confusing. I was trapped by this syntax >> only a week ago. It took me very long before I figured out what was >> happening. > > That's what started this discussion, there are a lot of questions > on the mailinglists about why != doesn't work like expected. > > I would vote for a preference value that defaults to make > ip != 10.0.0.1 result in !(ip.addr==10.0.0.1). > > It would be best to create a pop-up when the user uses the != operator > the first time (after upgrading Wireshark) telling them about the > difference and where they can change back it back to the old behaviour. > Even the warning window itself should have a "don't show this > message again" checkbox > > Stig, Ulf, Guy, Jaap, what do you think of such a compromise? > > Cheers, > Sake _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
