Wireshark · Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 38106: /trunk/epan/dissectors/ /trunk/epan/dissectors/:

["Maynard, Chris" <Christopher.Maynard@xxxxxxxxx>]

Well, an alternative could be to introduce something along the lines of:

 

#define proto_tree_add_int8_item(tree, hf, tvb, start)            proto_tree_add_item(tree, hf, tvb, start, 1, ENC_NA)

#define proto_tree_add_int16_le_item(tree, hf, tvb, start)        proto_tree_add_item(tree, hf, tvb, start, 2, ENC_LITTLE_ENDIAN)

#define proto_tree_add_int16_be_item(tree, hf, tvb, start)        proto_tree_add_item(tree, hf, tvb, start, 2, ENC_BIG_ENDIAN)

#define proto_tree_add_int32_le_item(tree, hf, tvb, start)        proto_tree_add_item(tree, hf, tvb, start, 4, ENC_LITTLE_ENDIAN)

#define proto_tree_add_int32_be_item(tree, hf, tvb, start)        proto_tree_add_item(tree, hf, tvb, start, 4, ENC_BIG_ENDIAN)

#define proto_tree_add_int64_le_item(tree, hf, tvb, start)        proto_tree_add_item(tree, hf, tvb, start, 8, ENC_LITTLE_ENDIAN)

#define proto_tree_add_int64_be_item(tree, hf, tvb, start)        proto_tree_add_item(tree, hf, tvb, start, 8, ENC_BIG_ENDIAN)

 

… and similarly for all the other proto_tree_add_*() functions that take a “little_endian” argument.

 

Another benefit of doing this would be that the length arguments would always be guaranteed to be correct for the type of field being added.

 

- Chris

 

 

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Anders Broman
Sent: Friday, July 22, 2011 6:11 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 38106: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-bacapp.c

 

Maynard, Chris skrev 2011-07-22 23:23:

My only problem with ENC_NA is that it is defined exactly the same as ENC_BIG_ENDIAN.  If you use ENC_NA in little-endian protocols, it is inevitable that “copy-and-paste” will occur at some point and then these endian bugs will start popping up because an ENC_NA was used where an ENC_LITTLE_ENDIAN should have been.

 

If ENC_NA was defined differently from ENC_BIG_ENDIAN, and if checks were made to be sure only valid ENC_*’s were passed to the proto_tree_add_xyz() functions for the particular FT_* field type, then I think it would make more sense (to me at least).  Right now, I still prefer to use ENC_LITTLE_ENDIAN throughout a little-endian protocol and ENC_BIG_ENDIAN throughout a big-endian protocol because it does no harm to do it and helps avoid future “copy-and-paste” bugs.  I just don’t see any particular advantage with using ENC_NA right now.  (Note that I only say that’s my personal preference; there seem to be more folks preferring ENC_NA, so I will use it too, I guess.)

 

+1 :-)
Anders

<snip>

 

 

 

 

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.