On Feb 21, 2014, at 8:15 AM, "John Dill" <John.Dill@xxxxxxxxxxxxxxxxx> wrote:
> From the topic discussion, I got the impression that not
> putting hf_register_info entries for Spare or Reserved fields
> was considered bad practice.
Some might consider it bad practice; I don't.
The only advantage to having it be a named field would be to be able to filter for a specific value for the field, or to check whether it's non-zero.
I'm not sure there's any point in filtering for specific values.
There might be some use for checking for non-zero values *if* the spare bits are supposed to be zero; that's why I suggested proto_tree_add_mbz(), if, for a given collection of spare bits, those bits Must Be Zero.
What *is* bad practice is using proto_tree_add_text() for an actual data value, as it can't be used to filter the display, can't be used in "find packet", can't be used to control the color of the packet, can't be used as a custom column, can't be dumped with "-T fields", etc..
I think we should add replacements for all the use cases of proto_tree_add_text() except for "this is an actual data value, but I don't want to add a named field for it" - it shouldn't be up to the dissector author to decide what fields the user should, and shouldn't, be able to refer to by name.
proto_tree_add_spare() and proto_tree_add_mbz() replaces the "these are spare bits and we want to have a protocol tree item for it" use case of proto_tree_add_text().