I'm continuing my work on the SNA dissector. Just about every field
so far is a bitfield. I'm getting tired of the way the proto_tree field
routines and bitfields interact.
1) Lots of information is dupicated during the proto_tree_add_item call,
not to mention the call has to be proto_tree_add_item_format().
usage:
proto_tree_add_item_format(bf_tree, hf_sna_rh_rri, offset, 1, rh_0 & 80,
decode_enumerated_bitfield(rh_0, 0x80, 8, sna_rh_rri_vals, "%s"));
Duplicates are variable rh_0, bitmask 0x80, width 8 (available in
registration), and val_string sna_rh_rri_vals (available in registration).
2) Furthermore, because the proto_tree code treats bitfields as ordinary
ints, the values are bit-shifted. For the value of the SNA field "FID":
0 0 1 0 . . . . FID = 2
the display filter would have to be: "sna.th.fid == 0x20, but it really
should be "sna.th.fid == 0x2".
So, I'm thinking about how to make the proto_tree code understand bitfields.
Registration would be something like:
{ &hf_sna_th_fid,
{ "Format Identifer", "sna.th.fid", FT_UINT8, NULL, mask, width, shift }}
"mask" and "width" are the same as in the decode_*_bitfield functions.
"shift" is the number of bits to shift to get the value. So I could
use
fid = pd[offset];
proto_tree_add_item(bf_tree, hf_sna_th_fid, offset, 1, fid);
So, my code doesn't worry about shifting, but the proto_tree code shifts
it before inserting it into the proto_tree.
The shifting might come more into play with an "enumerated" bitfield that
uses a val_string.
Anyway, I haven't tried to code any of this, so I'm not sure what the
implications are. Does anyone have any thoughts about this?
Also, I'm thinking about removing the field types FT_VAL_UINT*, since
we could simply mark these fields as FT_UINT*. The presence of a val_string
pointer tells us if the fields is FT_VAL_UINT* or not.
Thoughts?
--gilbert
