Re: Header field with scaling factor/units?

[Pascal Quantin <pascal.quantin () gmail com>]

Le 9 avr. 2014 20:02, "John Dill" <John.Dill () greenfieldeng com> a écrit :
> 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

Hi John,

This is the kind of use case where I personally use BASE_CUSTOM (see
explained in doc/README.dissector for details).

Regards,
Pascal.

___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe