Re: displaying header field without filtering

[Guy Harris <guy () alum mit edu>]

On Feb 21, 2014, at 8:15 AM, "John Dill" <John.Dill () greenfieldeng com> 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().
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe