Wireshark · Wireshark-dev: Re: [Wireshark-dev] Retrieving dissection result from another dissector

[Guy Harris <guy@xxxxxxxxxxxx>]

On Jul 4, 2018, at 2:27 AM, Dario Lombardo <lomato@xxxxxxxxx> wrote:

> On Tue, Jul 3, 2018 at 8:49 PM Guy Harris <guy@xxxxxxxxxxxx> 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.)