2016-07-18 17:44 GMT+02:00 Anders Broman <[email protected]>:
> 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. > proto_tree_set_uint is called too late currently: you have CHECK_FOR_NULL_TREE and TRY_TO_FAKE_THIS_ITEM calls before. We might do the masking / shift directly in proto_tree_add_item_ret_uint / proto_tree_add_item_ret_int / proto_tree_add_bitmask_with_flags_ret_uint64 directly but it means it will be done twice when you have a tree and not faking items... > > Regards > > Anders > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Pascal Quantin > *Sent:* den 18 juli 2016 15:40 > *To:* Developer support list for Wireshark <[email protected]> > *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 <[email protected]>: > > 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 <[email protected]> > To: wireshark-dev <[email protected]> > 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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe > <[email protected]?subject=unsubscribe> > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe > > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
