On Thu, Jul 21, 2011 at 9:45 PM, Bill Meier <[email protected]> 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)
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
