> The display filter code can easily be changed to find an field under
> *any* protocol, not just the one for which the field was registered.
Hmm.
If you're doing a display filter, you're not interested in most of the
fields that could be put into a protocol tree, you're only interested in
a subset of them (unless you've constructed a truly insane filter
expression).
If the display filter compiler built a list (array, whatever) of all the
hf_ values being tested by the current display filter, the code to build
the protocol tree could, if that list isn't empty (which it would be if
there are no plans to evaluate a display filter expression), check, when
putting an item into the protocol tree, whether the item's hf_ value is
in that list and, if so, add the protocol tree item to a list attached
to the entry for that hf_ value.
Then there wouldn't be a need to scan the protocol tree to evaluate a
display filter - the information needed for the display filter would
already be available.
(It's conceivable that one could represent display filter expressions in
a form where you can evaluate individual terms as the fields to which
they refer are entered into the protocol tree and, in some cases, cut
short the construction of the protocol tree as soon as you can tell for
certain whether the expression will evaluate to "true" or "false". For
example, with a display filter such as
smb.fid == 0x8080
once you've put an "smb.fid" entry into the tree with a value of 0x8080,
you know it'll evaluate to "true". Obviously, if you see one that
*isn't* 0x8080, you don't know one way or the other, as the semantics of
{field} {relation} {value}
are that it tests whether *any* instance of {field} is in the relation
in question to the value, so you can never determine whether a test is
false until you've build the entire display filter.
That might render this an uninteresting optimization, though, as a
filter is likely to evaluate to "false" on many packets.)