then the next step could be adding "...!=..." operator back to be equivalent to "!(...)".
/sunyin On Jan 29, 2008 3:55 AM, Jaap Keuter <[EMAIL PROTECTED]> wrote: > 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 > -- <img src="http://ed2k.selfip.org/favicon.gif"/>
_______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
![http://ed2k.selfip.org/favicon.gif"/](http://ed2k.selfip.org/favicon.gif"/){kind=link}