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 <[email protected]> To: Developer support list for Wireshark <[email protected]> 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 <[email protected]> wrote: > On Wed, Jul 9, 2014 at 10:06 PM, <[email protected]> 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 <[email protected]> > Archives: http://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: http://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: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
