proto_tree_add_text stats

[mmann78 () netscape net]

> From the "maybe you were curious, but afraid to ask" file, some stats I've collected on proto_tree_add_text calls:
 
1292 calls in the dissector directory [1] from 86 files (for an average of 15 calls per dissector that have at least 
one)
21 calls outside of the dissector directory, mostly in comments (all plugin dissectors have been converted)
 
There are only 3 dissectors flagged by checkAPIs.pl for "excessive" proto_tree_add_text use
1. packet-csn1.c (36) .  I've been told this is comparable to asn.1 dissectors.  It seems to me like hf_ items for 
proto_tree_add_item should be passed into the functions that call proto_tree_add_text, but every time I try to figure 
it out, it just makes my head hurt.  However there are sample captures out there (bug 7615 for example) if someone 
wants to take a shot.
2. packet-sigcomp.c (211). This was "hiding" in the epan directory outside of the dissector directory up until a few 
months ago.  It doesn't appear to be 211 separate fields, just a lot of reuse, but I don't understand enough (or can 
find sample captures) about it to take the plunge.  convert_proto_tree_add_text.pl could probably be used to lighten 
the load.  If this dissector is removed from the previous stats, the average per dissector drops to 12.
3. packet-wbxml.c (80).  This appears to be a tvb_parse candidate, but I've never seen a sample capture to attempt to 
make the conversion (and learn about tvb_parse in the process)
 
Outside of those 3, according to checkAPIs.pl [2]
1. There are 2 other dissectors that have more than 30 proto_tree_add_text calls
packet-bgp.c (45)
packet-bssgp.c (32)

2. There are 12 dissectors with 20-30 proto_tree_add_text calls
packet-ansi_801.c
packet-ansi_a.c
packet-dcerpc-spoolss.c
packet-dcerpc.c
packet-dvbci.c
packet-gsm_a_rr.c
packet-mih.c
packet-q2931.c
packet-q931.c
packet-rsvp.c
packet-rtps.c
packet-slsk.c

3. There are 21 dissectors with <= 5 proto_tree_add_text calls.
For many of these, I can't match the functionality "exactly" (or how fields _should_ be formatted) or when "complicated 
formatting" (or logic) is involved and I don't have a sample capture to verify against.

As you can tell from the commit logs, I work on this in fits and starts, but patches are always welcome.  I'll always 
defer/discard my work in progress to someone more familiar with a dissector.
 
 
[1] This is a simple grep and doesn't take into account comments, ignore header files, etc
[2] I've certainly come across a few cases where checkAPIs.pl results don't equal grep (even if you factor out 
comments), but overall its reliable for large numbers of proto_tree_add_text calls



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