Re: [Wireshark-commits] rev 38106: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-bacapp.c

[Alexis La Goutte <alexis.lagoutte () gmail com>]

On Thu, Jul 21, 2011 at 9:45 PM, Bill Meier <wmeier () newsguy com> 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 <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