Is the possibility to overload fields' definitions a controlled property which can be relied on?

Question

Probably one for the core development team.

The Lua API reference manual doesn't mention this, but if you define a ProtoField whose abbr matches an already existing one contributed by another dissector, it is accepted unless its definition differs from that of the existing one.

It is even possible to refer to your own translation table in the ProtoField definition, and such table may be a local one so it clearly doesn't interfere with the other dissector's one.

As this turned out to be quite useful, my question is whether it is a controlled property and thus it is going to stay like that and should be explicitly documented, or whether it has just "happened" and thus it cannot be relied upon for the future.

Accepted Answer

Yes, this is a feature and will thus likely stick around. From README.dissector:

It is OK to have header fields with a different format be registered with
the same abbreviation. For instance, the following is valid:
static hf_register_info hf[] = {
{ &amp;hf_field_8bit, /* 8-bit version of proto.field */
{ &quot;Field (8 bit)&quot;, &quot;proto.field&quot;, FT_UINT8, BASE_DEC, NULL,
    0x00, &quot;Field represents FOO&quot;, HFILL }},

{ &amp;hf_field_32bit, /* 32-bit version of proto.field */
{ &quot;Field (32 bit)&quot;, &quot;proto.field&quot;, FT_UINT32, BASE_DEC, NULL,
    0x00, &quot;Field represents FOO&quot;, HFILL }}

};