On Sat, Mar 23, 2002 at 01:38:45PM -0800, Guy Harris wrote:
> Gilbert, would it be possible to change the
>
> [[:alnum:]_.:]+
>
> Flex specification for field name/non-quoted string tokens to
>
> [[:alnum:]_-.:]+
>
> so that you *can* have hyphens in field names, IP addresses, and the
> like, without breaking the lexical analyzer's handling of [N-M]-style
> ranges?
BTW, a consequence of distinguishing between field names and unquoted
strings at the lexical level is that, if you have a host named "tcp",
for example, the expression
ip.addr == tcp
is treated as a comparison of an IP address with the protocol "tcp",
which gets an error.
Unfortunately, this one is a bit tricky to handle, as
ip.src == ip.dst
is currently a valid expression and does the test you'd expect (matching
only packets going from a given address to the same address).
I guess we could replace the STRING and FIELD tokens with a single type
of token (which I'll call "STRING", for the sake of discussion), which
would have, associated with it the raw string value and either:
1) the hfinfo pointer for the corresponding field, *if* the
string isn't quoted and its value matches a token name
or
2) a null pointer if the string is quoted or its value matches a
token name.
Then we'd get rid of the
entity(E) ::= FIELD(F). { E = F; }
production, and replace the
logical_test(T) ::= FIELD(F).
production with a
logical_test(T) ::= STRING(S).
production, and the code to handle it would fail if the hfinfo pointer
for "S" is null and use it as the argument to "sttype_test_set1()" if
it's non-null, succeeds, and have the
relation_test(T) ::= entity(E) rel_op2(O) entity(F).
production
1) fail if neither "E" nor "F" has an hfinfo pointer (a test for
17 == 34, or a test for 17 == 17, would be rather boring);
2) use the one with the hfinfo pointer as the field, if only one
of them has an hfinfo pointer;
3) if *both* have hfinfo pointers, then:
if both of them refer to protocols, return an error;
if one of them refers to a protocol, treat that one as a
string rather than a field;
if neither of them refers to a protocol, treat both of
them as fields.