Re: Header field with scaling factor/units?

[Guy Harris <guy () alum mit edu>]

On Apr 9, 2014, at 11:01 AM, "John Dill" <John.Dill () greenfieldeng com> wrote (in a font that gets rendered as rather 
small characters in my mail reader - you might want to use larger type to help out those of us with aging eyes):

> 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.

Unfortunately, while both scaling and appending units would be useful for a number of fields, we don't have mechanisms 
to support them.

> 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.

Currently, the header_field_info structure has a field named "display".  Originally, it was used only for numerical 
values, to control the base in which to display the number; it's now used for other field types to control how they're 
displayed as well.  In addition, for numerical fields, there are some flags that can be set to indicate how to 
interpret the next field...

...which is the "strings" field.

I might be inclined to, for numerical fields, divide the "display" field into a 4-bit field used for the base and 
another field indicating how the strings field is to be interpreted (currently, that's what we have, but they're 
implemented as bit flags, which means that there are mixtures of flags that might not make sense).

We could add an additional type, in which the "strings" field encodes a scaling factor and units; perhaps integral and 
floating-point scaling factors could have different types.  (I would include the scaling factor as a number, not a 
string.)

I would also rename "strings", while we're at it - I think "display" might have been called "base" in the old days.

> 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)?

We'd probably want to support both filtering on the raw and displayed value of a field.  We can already do that with 
"enumerated" fields - if you have a field with a value_string table that maps 2 to "Hello", then you can do

        proto.field == 2

or

        proto.field == "Hello"

We might want to add syntax so that, for a field with a scale factor of 0.5, we might have

        wlan.rate = raw(22)

or

        wlan.rate = 11

(no, that was not a randomly-chosen field example :-)).  Other suggestions for the syntax are welcome.
___________________________________________________________________________
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