proto_tree_add_subtree should be proto_tree_add_text + proto_item_add_subtree (where the return value of proto_tree_add_text is input to proto_item_add_subtree).
When I originally created proto_tree_add_subtree, I thought it would be "more optimized" to include the function body of proto_tree_add_text, rather than just call the function itself. It seems like Martin found a subtly in why that shouldn't be done (that I still don't understand).
However, the tree_item variable is intended to add as the "return value" for the "hidden" proto_tree_add_text, which dissectors can (and do) use to append more text or set the length to.
So perhaps the simplest fix is to just have proto_tree_add_subtree be what it really was intended to be - just proto_tree_add_text (as the function call) + proto_item_add_subtree.
Michael
-----Original Message-----
From: darkjames-ws <darkjames-ws@xxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Wed, Jul 30, 2014 1:32 am
Subject: Re: [Wireshark-dev] switching to proto_tree_add_subtree()
Hi,
On Tue, Jul 29, 2014 at 06:47:53PM -0400, Jeff Morriss wrote:
> >However, I don't quite understand why for tree!=NULL but not visible,
> >proto_tree_add_text() returns tree. I can see this in the code, we call
> >TRY_TO_FAKE_THIS_ITEM(), which returns the tree itself when it's not
> >visible. But what sense does this make for the caller?
>
> I think it's because while proto_trees are allowed to be NULL, we
> don't want (or the API is not ready for) proto_items to be NULL.
> (IOW that "return tree" quoted above is (ab)using the fact that a
> proto_item is a proto_tree.)
>
>
> Does this mean that this code in add_subtree_format() should be
> setting *tree_item to 'tree' (instead of NULL) here:
>
> > /* Make sure pi is initialized in case TRY_TO_FAKE_THIS_ITEM bails */
> > if (tree_item != NULL)
> > *tree_item = NULL;
Wouldn't be it simpler if we just remove 'tree_item' argument?
Cause I understand that after change *tree_item is always the same as return
value?
Regards,
Jakub.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe