[Pascal Quantin <pascal.quantin@xxxxxxxxx>]

Hi guys,

I was bugged by the same issue but contrary to Michael, I used the API and added the bit shift / masking manually from the output of proto_tree_add_item_ret_uint...

So I'm fine doing the change to take the mask into account (It would seem saner) but let's coordinate so that we can fix the dissectors accordingly (and not introduce new bugs ;) ).

Or we keep the current behavior but add a big warning in the function header to make the users aware of this behavior.

Pascal.

2016-07-18 15:04 GMT+02:00 Michael Mann <mmann78@xxxxxxxxxxxx>:

I've been wondering that myself, and I'm leaning towards "yes it should" because there have been many cases where I couldn't use proto_tree_add_item_ret_uint where I wanted to because masks were involved.

 

 

-----Original Message-----
From: Anders Broman <anders.broman@xxxxxxxxxxxx>
To: wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>
Sent: Mon, Jul 18, 2016 8:45 am
Subject: [Wireshark-dev] proto_tree_add_item_ret_uint() returns unmasked value - should it?

Hi,

proto_tree_add_item_ret_uint() returns the value corresponding to the length of the value fetched e.g uint8, uint16 etc but does not take the mask of

the hf entry into consideration which lead to a bug in an proprietary dissector I have.

Should it in fact return the value displayed in the corresponding hf variable e.g take the mask into consideration?

Regards

Anders   

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

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