["yin sun" <sunyin51@xxxxxxxxx>]

then the next step could be adding "...!=..." operator back to be equivalent to "!(...)".

/sunyin

On Jan 29, 2008 3:55 AM, Jaap Keuter <jaap.keuter@xxxxxxxxx> 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@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev

-- 
<img src="" href="http://ed2k.selfip.org/favicon.gif">http://ed2k.selfip.org/favicon.gif"/>