https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3538
--- Comment #8 from Jaap Keuter <jaap.keuter@xxxxxxxxx> 2009-06-27 05:19:49 PDT ---
>From README.developer:
<quote>
static hf_register_info hf[] = {
{ &hf_PROTOABBREV_FIELDABBREV,
{ "FIELDNAME", "PROTOABBREV.FIELDABBREV",
FIELDTYPE, FIELDBASE, FIELDCONVERT, BITMASK,
"FIELDDESCR", HFILL }
}
};
proto_PROTOABBREV = proto_register_protocol("PROTONAME", "PROTOSHORTNAME",
"PROTOABBREV");
proto_register_field_array(proto_PROTOABBREV, hf, array_length(hf));
</quote>
This duplication of definition of filter fields has always struck me as
somewhat odd.
First we set a display filter for the protocol, in proto_register_protocol(),
which is used when we put "PROTOABBREV" in the display filter.
Then we set header fields for this proto_PROTOABBREV which should have filter
fields starting with "PROTOABBREV.", but as we have seen sometimes do not.
What would be the consequences of automatically prefixing the "FIELDABBREV"
with "PROTOABBREV." derived from proto_PROTOABBREV ?
One obvious problem is the current codebase which already has this prefix in
place. That should be easily detected though, by comparing the "PROTOABBREV."
derived from proto_PROTOABBREV with the first part of the filter field.
Another is the increased processing in dissector registrations and the
increased memory footprint from the prefixed strings.
A different approach is to tighten up the registrations check. As with
FIELDTYPE, FIELDBASE, FIELDCONVERT the FIELDABBREV could be checked it has the
correct prefix. If not reject the registration.
I know a clean up of the FIELDTYPE, FIELDBASE, FIELDCONVERT has been taking
place so, maybe now it's time to put in these checks. For FIELDABBREV we could
consider the same.
Thoughts?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.