+1 for the double dot On Sun, Apr 15, 2018 at 10:28 PM, Jasper Bongertz <[email protected]> wrote:
> Hi, > > +1 for the double dot syntax. > > Cheers, > Jasper > > > Sunday, April 15, 2018, 3:03:53 PM, you wrote: > > > > > > > > > > > > > > > > *> 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 <* > [email protected] > > > > > > > *> 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 > <https://lekensteyn.nl> > > > *> > ___________________________________________________________________________ > > Sent via: Wireshark-dev mailing list <*[email protected] > *> > Archives: *https://www.wireshark.org/lists/wireshark-dev > *> Unsubscribe: *https://www.wireshark.org/mailman/options/wireshark-dev > > *> *> mailto:[email protected]?subject= > unsubscribe <[email protected]?subject=unsubscribe> > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
