Re: The 'in' display filter operation

[Hadriel Kaplan <the.real.hadriel () gmail com>]

I believe just in the past month sometime, someone was talking about
using the "{ }" braces in the display filter to indicate fields
grouped in the same application-layer PDU. So that for example a
filter like "{ foo && bar }" would only match true if foo and bar were
both true in the same PDU, as opposed to just the same frame packet.
(at least that's how I interpreted the emails, but I could be wrong)

But personally I like your syntax's meaning better - probably because
it looks like Lua. :)

The only downside I can see is it means we're using up one of the few
container-type token pairs left (the braces), for a feature that is
just a convenience. I.e., a user can already do the logic of "x in {a,
b, c}" today by doing "((x == a) or (x == b) or (x == c))". Whereas
for something like PDU-based groupings there is no way to do today.

Having said that... one could argue we could re-use braces for both
use-cases, and disambiguate based on the 'in' token. Because my guess
is the PDU-based grouping will also need to be more than simply "{ foo
&& bar }", but in fact something like "qux has {foo && bar}". (Where
"qux" identifies the protocol name of the PDU layer which foo and bar
need to both be true, as children somewhere under qux)

-hadriel

On Sat, Aug 22, 2015 at 11:11 PM, Jeffrey Smith <whydoubt () gmail com> wrote:
> I decided to try my hand implementing the 'in' operator.  I used the syntax
> 'x in {a,b,c}' (with commas).  In code I created a set type that contains a
> GSList of stnode_t's.  At the gencode layer, I effectively generate an OR-ed
> series of equality operations, but I cut out the redundant existence
> operations.  The DFVM was untouched.
>
> After doing this, I ran across doc/README.display_filter which proposes
> various implementations for the 'in' operator.  Also, it mentions this issue
> has been brought up at least as far back as 2004.  So what are the current
> thoughts on this?  Any significant reason that no implementation has made it
> in?
>
> It would be trivial for me to change to the 'x in {a b c}' syntax (no
> commas) if that is preferred.  However, I have not done any work toward
> handling contiguous ranges and have no plans to at present.
>
>  -- Thanks,
>  -- Jeff Smith
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe