Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] How to replace proto_tree_add_text()

Date: Fri, 22 Nov 2013 19:20:36 -0500 (EST)
I developed convert_proto_tree_add_text.pl (in tools dir) for just this reason.  See http://www.wireshark.org/lists/wireshark-dev/201307/msg00073.html for brief explanation.
 
If you're looking specifically at packet-ansi_a.c, I'm not sure how straightforward the conversion will be.  Without any knowledge of the protocol, I tried to look into using convert_proto_tree_add_text on it because packet-ansi_a.c is one of the worse offenders of proto_tree_add_text (over)use.  I didn't get far because I was confused by what I considered "extra logic" in trying to format fields and it just looks like the dissector needs an overhaul.
 
However if you're familiar with the protocol, I'll gladly assist you (you can email me directly) in trying to apply/use convert_proto_tree_add_text.pl to reduce the number of proto_tree_add_text calls.
 
Michael
 
-----Original Message-----
From: Guy Harris <guy@xxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Fri, Nov 22, 2013 5:39 pm
Subject: Re: [Wireshark-dev] How to replace proto_tree_add_text()


On Nov 22, 2013, at 2:10 PM, Michael Lum <michael.lum@xxxxxxxxxxxxxxxxx> wrote:

> I ran the checkAPIs.pl script against the files I have modified and it 
complains about a lot of proto_tree_add_text() calls.
>  
> I would like to fix them but after looking at the README.dissector document 
I'm left wondering if there is an easier way
> than using proto_tree_add_item.
>  
> The places in the dissector where add_text() is used were for labelling parts 
of the protocol without having to create
> filterable fields.

A better term is "named fields", as a field's name can be used in places other 
than filter expressions - which, themselves, should perhaps be called 
"packet-testing expressions", as they're used for more than filtering; they can 
be used for coloring as well.

This means that:

> For example, in packet-ansi_a.c there are 457 useless add_text() calls vs 26 
add_<something else>() calls.
>  
> Do I have to add 457 items (approximately, some may duplicate) to 
hf_register_info ?
>  
> Basically, I want to just label a bunch of bits or octets, no subtree, not 
filterable.

...a named field is more than "filterable"; it can be used to make a custom 
column, or can be used in TShark output with "-T fields", and possibly other 
places I've forgotten about.

That's why we encourage making named fields and using them - somebody might find 
a use for them, even if you don't have a use for them.
___________________________________________________________________________
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