Wireshark · Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 38106: /trunk/epan/dissectors/ /trunk/epan/dissectors/:

[Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>]

On Thu, Jul 21, 2011 at 9:45 PM, Bill Meier <wmeier@xxxxxxxxxxx> wrote:

On 7/21/2011 3:35 PM, Jeff Morriss wrote:

Guy Harris wrote:

On Jul 18, 2011, at 10:19 PM, Maynard, Chris wrote:

Assuming the reporter of bug 5769 is correct and the Info column
displays the values of the low and high limits correctly, then the
protocol is ENC_BIG_ENDIAN. All of the fields affected by r38106 are
either FT_UINT8's or FT_BOOLEAN's spanning 1 byte, so endian-ness
really doesn't matter, but if someone does the old "copy-and-paste"
thing later on, [s]he might incorrectly copy an ENC_LITTLE_ENDIAN
when it should be ENC_BIG_ENDIAN.

If they're all one-byte fields, they might as well be ENC_BIG_ENDIAN,

I had wondered about that when converting some dissectors to ENC_XXX. I
ended up using ENC_NA for one-byte fields since it really is "not
applicable," but I'm not sure that was the Right thing to do. If all the
other fields are ENC_BIG_ENDIAN that I guess it would make sense to just
keep using that, even for one-byte fields.

My somewhat mild preference is to use ENC_NA for one-byte fields....

+1

I use ENC_NA for FT_BYTES/FT_(U)INT8/FT_STRING/FT_BOOLEAN....

Why not add a check in checkhf.pl? (if proto_tree_add_item end by ENC_NA /ENC_BIG_ENDIAN / ENC_LITTLE_ENDIAN)