On Wednesday, July 9, 2003, at 9:58 PM, Gilbert Ramirez wrote:
I'm working on some changes to the dfilter code, and would like to have
the scanner create some of the basic types. But floating point 0.7
looks
like a byte-string equivalent to 00:07. In order to disambiguate some
floating point numbers from two-byte byte-strings, I'd like to remove
the option of using a period between bytes in a byte-string.
Is there any situation where it can't be disambiguated in context?
I.e., a case where "0.7" appears where it would be a valid expression
regardless of whether it's interpreted as a floating-point number or a
byte string?
A scheme wherein the scanner did as little work as possible, and the
interpretation of tokens was done by, for example, code associated with
a given FT_ type, might be more easily extensible.
I'd like to get a feel for how badly this change would affect people.
If
breaking this would cause too much hardship, I won't do it. I can work
around the 3 syntaxes for byte strings. I'm contemplating this change
because it makes it easier and cleaner to implement a "contains" test.
I.e., I have the following dfilter syntax working:
http contains "jpg"
frame contains 00:07
The "contains" test works on protocols, strings, and byte-strings (and
derivatives).
So that sounds like a case where 0.7 would have to be a byte string.