>Message: 1
>Date: Fri, 21 Feb 2014 11:42:33 -0800
>From: Guy Harris <guy@xxxxxxxxxxxx>
>To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>Subject: Re: [Wireshark-dev] displaying header field without filtering
>Message-ID: <AA970EBD-3C3B-4F05-8996-31CE6319F088@xxxxxxxxxxxx>
>Content-Type: text/plain; charset=iso-8859-1
>
>
>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().
Sounds reasonable to me.
Best regards,
John Dill
<<winmail.dat>>
