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.
+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)
