Re: Retrieving dissection result from another dissector

[Guy Harris <guy () alum mit edu>]

On Jul 4, 2018, at 2:27 AM, Dario Lombardo <lomato () gmail com> wrote:

> On Tue, Jul 3, 2018 at 8:49 PM Guy Harris <guy () alum mit edu> wrote:
>
> > Should we, instead, get rid of the scope arguments to those functions and, instead, have separate functions, one of 
> > which serves the original purpose, using file scope, and one of which serves this new purpose, using pinfo->pool 
> > scope?
>
> It looks neat, but I see 2 issues:
>
> 1) grep -r  "p_\(add\|get\|remove\)_proto_data" ../epan/dissectors/* | wc -l gives me 881 calls to those functions. 
> It could be harsh to change all of them

Time for me to learn Coccinelle:

        http://coccinelle.lip6.fr

and download and install it.  (An ed script could probably do a lot of it, but it's past time to get Coccinelle into my 
toolkit.)

> as well as breaking compatibility with existing code outside wireshark (plugins?).

We don't guarantee API compatibility between major or dot releases, only between dot-dot releases.

> 2) are we sure that a call to (eg.) p_proto_add_data_with_file_scope_or_another_name() is more meaningful than 
> p_proto_add_data(wmem_file_scope(), ...)? How could those 2 functions be named to recall the actual goal?

{add,get}_persistent_proto_data()

{add,get}_per_layer_packet_info()

or something such as that.  The scope isn't relevant, the *purpose of the data* is relevant, and dictates the scope to 
use.

(It also removes the possibility to get the scope wrong, using a scope not supported by the routines.)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe