Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 38106: /trunk/epan/dissectors/ /trun
From: "Maynard, Chris" <[email protected]>
Date: Tue, 19 Jul 2011 01:19:01 -0400
> -----Original Message-----
> From: [email protected] [mailto:wireshark-commits-
> [email protected]] On Behalf Of [email protected]
> Sent: Monday, July 18, 2011 11:20 PM
> To: [email protected]
> Subject: [Wireshark-commits] rev 38106: /trunk/epan/dissectors/
> /trunk/epan/dissectors/: packet-bacapp.c
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=38106
> User: guy
> Date: 2011/07/18 08:20 PM
> Log:
>  Use ENC_LITTLE_ENDIAN rather than TRUE in proto_tree_add_item() calls.
>  (Yes, that means that all but one call uses ENC_LITTLE_ENDIAN, and one
>  uses ENC_BIG_ENDIAN.  I guess that's how the protocol works....)
> Directory: /trunk/epan/dissectors/
>   Changes    Path               Action
>   +33 -34    packet-bacapp.c    Modified

Isn't this more confusing now?  I don't have access to the BACnet standard, but surely it's either big or little endian and not some mix of both?  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.

CONFIDENTIALITY NOTICE: The contents of this email are confidential
and for the exclusive use of the intended recipient. If you receive this
email in error, please delete it from your system immediately and 
notify us either by email, telephone or fax. You should not copy,
forward, or otherwise disclose the content of the email.