Hi,
In fact I would suggest to consider double dot (‘..’) in this case.
Reasons:
* It is a sufficiently unique operator
* The minus causes too many conflicts, as you have stated
* triple dot (‘...’, i.e. Ellipsis) is too prone to ‘autocorrection’ to the ellipsis symbol, causing copy-paste problems.
Regards,
Jaap
> On 15 Apr 2018, at 13:24, Peter Wu <peter@xxxxxxxxxxxxx> wrote:
>
> Hi,
>
> Laura requested support for ranges for the "in" display filter operator
> in bug 1480 which seems like a reasonable idea. I have a prototype patch
> working here: https://code.wireshark.org/review/26945
>
> The initial implementation converted "f in {a-b}" to "f >= a && f <= b",
> but this turned out to be problematic when a field has multiple
> occurrences. To solve this, I added a new ANY_IN_RANGE DVFM instruction
> that checks each field against the range.
>
> One remaining issue is the syntax. The proposed syntax looks a bit ugly
> with negative numbers, and is also not implemented for things other than
> numbers. It can also be ambiguous.
>
> Example: find SMB server timezone within UTC-0700 and UTC-0400):
>
> smb.server_timezone in {-420--240}
>
> Example: find all hosts in range 10.0.0.10-10.0.0.60. The CIDR notation
> cannot be used to match this, instead you need something verbose like:
>
> (ip.src >= 10.0.0.10 and ip.src <= 10.0.0.60) or
> (ip.dst >= 10.0.0.10 and ip.dst <= 10.0.0.60)
>
> A potential shorter version (not supported at the moment):
>
> ip.addr in {10.0.0.10-10.0.0.60}
>
> Another issue: the filter "data.data==1-3" is interpreted as matching
> bytes "0103" (because data.data is of type FT_BYTES). The display filter
> "data.data in {1-3}" is currently ambiguous (previously it matched the
> previous "==" filter, after my patch it becomes "a single byte in range
> 01 to 03"). One way to address this is to treat only "01:02:03" as byte
> patterns and forbid "01-02-03".
>
>
> With these cases, do you think that using "-" is a good range operator
> for the set membership operator? An alternative range syntax suggestion
> was proposed in doc/README.display_filter as:
>
> (x in {a ... z})
>
> Some possible ideas (I don't really like them to be honest):
>
> tcp.srcport in { 80 1662 ... 1664 }
> tcp.srcport in { 80 1662 .. 1664 }
> tcp.srcport in { 80 [1662, 1664] }
> tcp.srcport in { 80 range(1662, 1664) }
>
> Feedback is welcome!
> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
