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 <[email protected]>
To: Developer support list for Wireshark <[email protected]>
Sent: Wed, Jul 4, 2018 5:28 am
Subject: Re: [Wireshark-dev] Retrieving dissection result from another dissector






On Tue, Jul 3, 2018 at 8:49 PM Guy Harris <[email protected]> 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 
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 <[email protected]>Archives:    
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev             
mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Reply via email to