My objection to using p_proto_add_data in the particular case (passing data between dissectors) is that it makes the code/flow much harder to read and mistakes can result (usually found through fuzztesting) because the data flow isn't obvious. I think the most "common" case is still a dissector using p_proto_add_data to remember data "for itself" (which would include some interaction with GUI like Decode As). Just because you can exchange data between dissectors this way, doesn't mean you should. I think it's more understandable if there are multiple layers/protocols between the setting of data and it's retrieval, but if you are only going a single layer, the data parameter of call_dissector_with_data should be used and a "shared structure" should be defined that includes the input/output parameters.
-----Original Message-----
From: Dario Lombardo <lomato@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Wed, Jul 4, 2018 5:28 am
Subject: Re: [Wireshark-dev] Retrieving dissection result from another dissector
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 as well as breaking compatibility with existing code outside wireshark (plugins?).
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?
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-
dev@xxxxxxxxxxxxx>
Archives:
https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe