Wireshark · Wireshark-dev: [Wireshark-dev] Bitfield handling in proto_tree_add_uint_format()

[Alexey Neyman <avn@xxxxxxxxxxx>]

Hi all,

I have the following question: in the dissector I am writing, there is a 
bitfield occupying bits [2..7] of a byte. I have defined it as follows:

{ &hf_x, { "X", "p.x", FT_UINT8, BASE_HEX, NULL, 0xfc, "", HFILL }}

Everything is okay if I add that field using proto_tree_add_item(). 
However, the following code fails:

  x = tvb_get_guint8(tvb, 0) >> 2;
  proto_tree_add_uint_format(tree, hf_x, tvb, 0, 1, x,
	"the value of X formatted in some way");

The problem is that the value assigned to the "p.x" variable for packet 
matching is shifted 2 bits right one more time in proto_tree_set_uint(). 
Workaround is easy: for such fields, the bitmask could be specified as 
zero in header_field_info. I looked for other dissectors which might have 
faced such issue; in fact, epan/dissectors/packet-cimd.c just employs 
such workaround.

However, I wonder if this is a known and desired side-effect of 
proto_tree_add_uint_format() that makes its behavior different from 
proto_tree_add_item(). The doc/README.developer does not appear to 
mention that proto_tree_uint_format() takes not "final value" for fields 
with a bitmask, but rather raw, "unshifted" value.

Best regards,
Alexey Neyman.