Wireshark mailing list archives
Re: displaying header field without filtering
From: "John Dill" <John.Dill () greenfieldeng com>
Date: Mon, 24 Feb 2014 08:38:22 -0500
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
Current thread:
- duplicate field names (was: displaying header field without filtering), (continued)
- duplicate field names (was: displaying header field without filtering) Hadriel Kaplan (Feb 20)
- Re: duplicate field names (was: displaying header field without filtering) Pascal Quantin (Feb 20)
- Re: duplicate field names (was: displaying header field without filtering) Hadriel Kaplan (Feb 20)
- duplicate field names (was: displaying header field without filtering) Hadriel Kaplan (Feb 20)
- Re: displaying header field without filtering John Dill (Feb 20)
- Re: displaying header field without filtering Guy Harris (Feb 20)
- Re: displaying header field without filtering John Dill (Feb 21)
- Re: displaying header field without filtering Alexis La Goutte (Feb 21)
- Re: displaying header field without filtering Guy Harris (Feb 21)
- Re: displaying header field without filtering Jeff Morriss (Feb 24)
- Re: displaying header field without filtering John Dill (Feb 21)
- Re: displaying header field without filtering John Dill (Feb 24)