Wireshark-dev: Re: [Wireshark-dev] Problems with bitmasks and 64 bit values

From: Pascal Quantin <pascal.quantin@xxxxxxxxx>
Date: Tue, 1 Nov 2016 12:05:17 +0100

Le 1 nov. 2016 11:47, "Thomas Wiens" <th.wiens@xxxxxx> a écrit :
>
> On 31.10.2016 17:02, Pascal Quantin wrote:
>
> > Looks like no one is currently working on it (or at least no patch is
> > queued in Gerrit yet). As you seem to be the fist user of those functions
> > with 64bits fields, you are probably a good candidate to submit a patch as
> > you can easily test it ;)
> > 64 bits variant should make use of the hf_try_val64_to_str_const(),
> > *custom_fmt_func_64_t() and hfinfo_number_value_format64() functions.
>
> It's not clear of how to use the bitmask in the readme documentation.
> In my opinion, it looks best when the fields of the bitmask tree have
> the same number of bits as the main headerfield. If the main hf has
> FT_UINT64 and I add fields with FT_INT16 as Guy mentioned, then you
> can't see the position of the values (see attached example).

I agree it looks better with FT_(U)INT64

>
> But with the changes I've made to the proto_item_add_bitmask_tree()
> function, if you are using a type greater that FT_UINT40/FT_INT40, then
> you must use val64_string, even if you value for you value_string has
> only 1 byte.
> But I could check the display flags for BASE_VAL64_STRING and decide
> which one to use. I think it's the best way to prevent it from affecting
> dissectors which don't use always val64_string.
>
> Any opinions?

Why not simply select the right function based on ft type? For FT_(U)INT40 and above use the functions I indicated earlier.

>
> --
> Thomas
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe