Hi,
From a code point of view (epan/proto.c) I can see why this is
happening. From a API point of view this looks wrong. If I'm serving the
function the value to work with I expect it to work with that value, not
its own interpretation of it.
Let's have a look at what happens if we change this.
Thanx,
Jaap
Alexey Neyman wrote:
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.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
