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@xxxxxxxxx> 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@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
