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