Re: displaying header field without filtering

["John Dill" <John.Dill () greenfieldeng com>]

> Message: 1
> Date: Fri, 21 Feb 2014 11:42:33 -0800
> From: Guy Harris <guy () alum mit edu>
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> Subject: Re: [Wireshark-dev] displaying header field without filtering
> Message-ID: <AA970EBD-3C3B-4F05-8996-31CE6319F088 () alum mit edu>
> Content-Type: text/plain; charset=iso-8859-1
>
>
> 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().

Sounds reasonable to me.

Best regards,
John Dill

<<winmail.dat>>

___________________________________________________________________________
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