Re: proto_tree_add_subtree[_format]

[mmann78 () netscape net]

Adding a subtree requires (up to) 2 additional arguments (ett and if proto_item* is still going to be used), and I just 
thought it would be "API bloat" to add a proto_tree_add_item_with_subtree (and all of the other possible combinations). 
 proto_item_add_subtree still has its uses ;)
 
Next piece of functionality that I would like to target is using proto_tree_add_bitmask a lot more as that is another 
reason for a lot of the subtrees (some that I left with proto_tree_add_text so I would remember that's what they're 
there for), and it would make the dissector code itself a lot smaller/simpler.
 
 
-----Original Message-----
From: Alexis La Goutte <alexis.lagoutte () gmail com>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Thu, Jul 10, 2014 6:45 am
Subject: Re: [Wireshark-dev] proto_tree_add_subtree[_format]


On Thu, Jul 10, 2014 at 5:29 AM, Evan Huus <eapache () gmail com> wrote:
> On Wed, Jul 9, 2014 at 10:06 PM, <mmann78 () netscape net> wrote:
> > I finished the conversion of proto_tree_add_text calls that were acting as
> > "subtree labels" into proto_tree_add_subtree[_format].  This removed almost
> > 4000 calls in the dissector directory (over 4000 if you include the plugins)
> > and brings the current total proto_tree_add_text count in the dissector
> > directory to 5831 (6586 over entire wireshark master trunk).  Of the 5831,
> > checkAPIs.pl considers 4690 to be "useless". (I believe the criteria being
> > using printf style arguments and no return value (like when it's intended as
> > a subtree label)).
Thanks Michael for the big work.. :-)
> What about the last ~1000 "not useless" ones? How are they used?
>
> > Since "subtree label" is the last "legimate" reason to use
it is no possible to add subtree also with hf field ?

> > proto_tree_add_text, should it be added as a "soft-deprecated API" to
> > checkAPIs script?
>
>
> If there really are no remaining legitimate uses, then +1.
+1
> > I wasn't sure if that was just being too obnoxious at the moment.  It may
> > need its own "paragraph" with suggestions on what to use instead (make field
> > filterable, expert info, subtree label)
>
>
> Obnoxious would be hard-deprecated :)
>
> How many actual c-files are those remaining add_text elements in? I imagine
> the majority of dissectors are now completely "clean" so it wouldn't be too
> bad.
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

 

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