Bug 8942 - proto_tree_add_item() calls should use ENC_ values rather than TRUE
proto_tree_add_item() calls should use ENC_ values rather than TRUE
Status: RESOLVED FIXED
Product: PIDL
Classification: Unclassified
Component: wireshark
svn
All All
: P5 normal
: ---
Assigned To: Jelmer Vernooij
Jelmer Vernooij
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-14 19:18 UTC by Guy Harris
Modified: 2012-05-15 10:21 UTC (History)
0 users

See Also:


Attachments
Patch to use ENC_ values for proto_tree_add_item() calls (1014 bytes, patch)
2012-05-15 01:39 UTC, Guy Harris
guy: review?
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guy Harris 2012-05-14 19:18:34 UTC
As of Wireshark 1.4, calls to proto_tree_add_item() should take an ENC_ value or a combination of those values to specify the encoding of the item being fetched from the packet; the last argument is no longer a Boolean specifying only the byte order.

For integral, floating-point, and Boolean fields, IPv4 addresses, GUIDs, and "counted byte array" fields (FT_UINT_BYTES), ENC_BIG_ENDIAN should be used rather than FALSE and ENC_LITTLE_ENDIAN should be used rather than TRUE.  (For IPv4 addresses, ENC_BIG_ENDIAN is almost always correct, although there's one protocol that sends out little-endian, i.e. byte-swapped from network byte order, IPv4 addresses!)

For FT_NONE fields, protocols, MAC and IPv6 addresses, OIDs, and byte sequences (FT_BYTES), ENC_NA ("Not Applicable") should be used.

For character strings, for current releases, ENC_NA should be used; for the upcoming 1.8 release, that should be combined with a character encoding such as ENC_ASCII (8-bit bytes with the 8th bit never set, i.e. *only* ASCII), ENC_UTF_8, ENC_UTF_16, ENC_UCS_2, and ENC_EBCDIC.
Comment 1 Guy Harris 2012-05-14 19:22:24 UTC
(A quick look at the PIDL generator seems to indicate that it's using proto_tree_add_item() for "aggregate" values such as structures; an "aggregate" value is probably either FT_NONE or FT_BYTES, in which case it should use ENC_NA.  I'm not sure about the bitmaps, but presumably those are *supposed* to be in the sender's byte order, which is not *guaranteed* to be little-endian - when Apple still sold PowerPC machines, its implementation of DCE RPC in the SMB client sent stuff over the wire in big-endian format.)
Comment 2 Guy Harris 2012-05-15 01:39:11 UTC
Created attachment 7560 [details]
Patch to use ENC_ values for proto_tree_add_item() calls

Here's a patch for this.

It appears that the integral value containing the bits in a bitmap should be dissected according to the data representation, as the individual fields are fetched by dissect_ndr_XXX, which is passed the data representation and extracts the value appropriately for the data representation, so the patch replaces TRUE (which meant "always little-endian" when the last argument to proto_tree_add_item() was a byte-order Boolean) with DREP_ENC_INTEGER(drep) (which means "ENC_BIG_ENDIAN or ENC_LITTLE_ENDIAN, depending on the data representation").

For structures, I'm just using ENC_NA.
Comment 3 Jelmer Vernooij 2012-05-15 10:21:30 UTC
Merged, landed in a66865dd287073f21ce279d52450582ea290c7df

Thank you!