I have a common use case (hundreds to low thousands of data elements) where I 
need to take some data, encoded in an integer FT_UINT[8|16|32], sometimes has a 
bitmask applied, and needs to be multiplied by a scaling factor that may be an 
integer or floating point value, with an optional units string.  I didn't see a 
use case in README.developer that directly handles this scenario.

I'm thinking about doing something like the following.

\code idea
proto_item *pi;
header_field_info *hf;

/* hf_index is the registered hf identifier */

pi = proto_tree_add_item(tree, hf_index, tvb, offset, length, ENC_BIG_ENDIAN);
hf = proto_registrar_get_nth(hf_index);
value = tvb_get_ntohX(tvb, offset);
tmpval = (value & hf->bitmask) >> hf->bitshift;
dblval = tmpval * scaling_factor;
if (units_str) {
  proto_item_set_text(pi, "%s: %f %s", hf->name, dblval, units_str);
} else {
  proto_item_set_text(pi, "%s: %f", hf->name, dblval);
}
\endcode

I can wrap this kind of code in one or more function(s), but I'm wondering if 
there is a recommended "Wireshark standard" solution.

Since at the moment it appears that I need to overwrite the item's text string 
to accomplish what I want, I was considering hijacking the 'strings' member to 
store the scaling factor and units strings.  Then I could test for the 
existence of a scaling factor/units string in the hf->strings member.  I'll 
probably have to package it into a VALS and use try_val_to_str to access the 
units string to remain compatible with 'proto_tree_add_item' before I rewrite 
the text representation.    The scale factor code be encoded as a string where 
I'd have to convert it on the fly using some form of strto[d|l|ul].  Of course 
this could be just added inline with the dissector code, but it would be nice 
to have a place in the hf_register_info declaration that documents this 
information.

I would think it would be possible to extend the FT_ types with a constant, 
that informs the api that the scaling factor and units are encoded in 
'hf->strings' as [{ 0, "0.25" } { 1, "pounds" }] with a new interface function 
or two to implement it.

Any thoughts on applying the proto_item_add_xxx interface to handle this use 
case?

How difficult would it be to allow a filter expression to be able to search on 
a header field whose condition assumes that the scaling factor has been 
applied, i.e., the data is an integer and has a scaling factor of .25 and you 
want to filter its value using a floating point value (probably quite difficult 
I'm guessing)?

Thanks for any comments,
John Dill
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Reply via email to