Wireshark mailing list archives
Re: Calling a dissector: Type for data parameter
From: João Valverde via Wireshark-dev <wireshark-dev () wireshark org>
Date: Mon, 21 Jun 2021 19:21:02 +0100
On 16/06/21 15:36, David Perry wrote:
Sorry to drag up an old topic, but I've been thinking about this:Message: 5 Date: Sat, 29 May 2021 09:32:29 +0200 From: Anders Broman <a.broman58 () gmail com> To: Developer support list for Wireshark <wireshark-dev () wireshark org> Subject: Re: [Wireshark-dev] Calling a dissector: Type for data parameter Message-ID: <CAOpyz=zDycm33PXUwtBCTew7gTTEcSLiJ-f8SHW0L-863Q517A () mail gmail com> Content-Type: text/plain; charset="utf-8" Hi, Yes the method is fragile. At the time of development I think it was proposed to pass a struct containing a string and the void pointer where the string could be used as a identifier. But that was voted down. Regards AndersI wasn't around for that discussion so I don't know the reasons, but how does this sound as a refined approach?:* Define a `dissector_data_t` that has a `guint32` identifier field, and a `void *` data field.* Replace the `void *data` parameter to dissectors with a pointer to a `dissector_data_t`.* Either:* Easy way: maintain a static list of identifiers that map to expected data types, or* Have dissector X request an identifier in its registration function for the type of data it expects, and have dissector Y (which will call X) request, in its handoff function, the identifier of the type of data it needs to pass to X.* Dissectors check for the right identifier in their `dissector_data_t` parameter and don't try to use it if it's wrong.Thoughts?
I think what you suggest would be the most straightforward fix.To avoid breaking backward compatibility and changing thousands of dissectors at the same time, both of which are highly problematic, it can be done by adding a new dissector type (like it was done with "dissector_cb_t", only using a different signature).[1]
Also a giant static list of dissector_data_t type identifiers would be pretty clunky. I think we could recycle the protocol registration number for that.
João [1]https://gitlab.com/wireshark/wireshark/-/blob/master/epan/packet.h#L79
David___________________________________________________________________________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
___________________________________________________________________________ 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
Current thread:
- Re: Calling a dissector: Type for data parameter David Perry (Jun 16)
- Re: Calling a dissector: Type for data parameter Hardening (Jun 16)
- Re: Calling a dissector: Type for data parameter João Valverde via Wireshark-dev (Jun 21)
- Re: Calling a dissector: Type for data parameter John Thacker (Jun 21)
- Re: Calling a dissector: Type for data parameter João Valverde via Wireshark-dev (Jun 21)
- Re: Calling a dissector: Type for data parameter John Thacker (Jun 21)
- Re: Calling a dissector: Type for data parameter João Valverde via Wireshark-dev (Jun 21)
- Re: Calling a dissector: Type for data parameter John Thacker (Jun 21)