Hi, The way it's working looks ok to me: Value = 1010 1010 Proto_add_item() 1010 10.. Ox2a
x = tvb_get_guint8(tvb, 0) >> 2; X = 0010 1010 proto_tree_add_uint_format(tree, hf_x, tvb, 0, 1, x, > "the value of X formatted in some way"); Value = 0010 10.. 0x0A as a mask is used in hf_xx Regards Anders -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jaap Keuter Sent: den 19 november 2007 17:31 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Bitfield handling inproto_tree_add_uint_format() 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@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
