Wireshark mailing list archives

Re: Is there some reason why the list in the "in" operator in packet-matching expressions must be separated by spaces, not commas?


From: Peter Wu <peter () lekensteyn nl>
Date: Thu, 18 Oct 2018 14:28:55 +0200

On Wed, Oct 17, 2018 at 12:35:34PM -0700, Guy Harris wrote:
In

      https://ask.wireshark.org/question/5530/what-is-the-expected-valueformat-for-display-filter-in/

somebody asks why

      tcp.stream in {1,8,12,18}

doesn't work.

The answer is "you have to separate them with spaces".

Is there some reason why they *must* be separated by spaces, rather than by allowing, for example, commas or 
semicolons?

The feature was added in v1.99.10rc0-86-g80322d88da, apparently with the
use case for specifying a set of ports.

This set membership operator was recently extended with range support:
https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html#_membership_operator

Numbers are not the only supported elements for this set. Consider:

    ip.addr in {10.0.0.5 .. 10.0.0.9 192.168.1.1..192.168.1.9}

If commas were added, it would not become more readable IMO:

    ip.addr in {10.0.0.5 .. 10.0.0.9, 192.168.1.1..192.168.1.9}

It could be made optional, but I am concerned that people accidentally
write a comma instead of a period and end up with strange errors:

    ip.addr in {10.0.0,3 1.0.0.5}

Currently it'll interpreted as two set elements. After allowing optional
commas, it might be three.

One reason that comes to mind, for floating-point numbers, is that, if we use the locale's decimal separator in 
filter expressions, a comma might be the decimal separator, i.e.

Is support for different decimal separators actually desired? Consider
1.234,56, this could be interpreted as one (1234.56), two (1, 234.56 or
1.234, 56) or three (1, 234, 56) numbers depending on interpretation. I
think it's better to keep it less ambiguous and just allow one notation.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe

Current thread: