>Message: 1 >Date: Fri, 21 Feb 2014 11:42:33 -0800 >From: Guy Harris <g...@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-31ce6319f...@alum.mit.edu> >Content-Type: text/plain; charset=iso-8859-1 > > >On Feb 21, 2014, at 8:15 AM, "John Dill" <john.d...@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-requ...@wireshark.org?subject=unsubscribe
