Comment # 9
on bug 11860
from João Valverde
(In reply to hvgeekwtrvl from comment #8)
> (In reply to Guy Harris from comment #7)
> > (In reply to João Valverde from comment #6)
> > > The most natural formal interpretation would be an AND relation, which the
> > > operator doesn't follow anyway, for convenience.
> >
> > I.e., the _expression_ {field} {op} {value} should be interpreted as "for all
> > instances of {field}, the relation '{value of that instance of the field}
> > {op} {value}' is true", rather than as "there is an instance of {field} such
> > that the relation '{value of that instance of the field} {op} {value}' is
> > true"?
> >
> > That would mean that "ip.addr == 192.168.0.1" would only match packets from
> > 192.168.0.1 to 192.168.0.1; I'm not sure that would be useful.
>
> The issue comes down to
> CASE {OP}:
> '==' : IF ANY instance of {field} {op} {value} : True
> '!=' : IF ALL instance of {field} {op} {value} : True
> ECASE : False
>
> The interpretation of the search is different for different {op} fields.
> The 'ip.addr ==' interprets as source OR destination where as 'ip.addr !='
> interprets as source AND destination.
I was suggesting to implement the operators differently: '==' implies OR and
'!=' implies AND. Does that make sense?
I understand it is inconsistent, possibly aesthetically unpleasing, and open to
interpretation as a bug. But, barring any implementation issues I'm not
foreseeing, in practice would it not improve the usability of the filter
mechanism for 99% of Wireshark users?
You are receiving this mail because:
- You are watching all bug changes.