[Anders Broman <anders.broman@xxxxxxxxxxxx>]

Hi,

I’m also OK either way but as Pascal says taking the mask into account seems more sane.

 

How about changing

static void

proto_tree_set_uint(field_info *fi, guint32 value)

to return integer and use that.

 

Regards

Anders

 

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Pascal Quantin
Sent: den 18 juli 2016 15:40
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] proto_tree_add_item_ret_uint() returns unmasked value - should it?

 

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