> -----Original Message-----
> From: wireshark-commits-bounces@xxxxxxxxxxxxx [mailto:wireshark-commits-
> bounces@xxxxxxxxxxxxx] On Behalf Of guy@xxxxxxxxxxxxx
> Sent: Monday, July 18, 2011 11:20 PM
> To: wireshark-commits@xxxxxxxxxxxxx
> 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.