Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Question for data argument of dissector_try_heuristic

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 25 Mar 2013 17:35:34 -0700
On Mar 25, 2013, at 1:57 PM, Roland Knall <rknall@xxxxxxxxx> wrote:

> Under Mac OS X some warnings came up, and among them is a repeated
> warning about an unused *data parameter for every call to a heuristic
> dissector.

Or, rather, a repeated warning about an unused *data parameter in every *definition* of a heuristic dissector *that doesn't use it or explicitly flag it as unused*.

No existing dissectors use it, but they all flag it as unused, so the warnings do *not* come up when you compile the Wireshark trunk; they only show up if you're adding your own dissector, or have changed an existing dissector, and have a heuristic dissector that doesn't use the argument and doesn't flag it as unused.

> As I do use the heuristic dissector, but do not use the
> data argument, I looked up every occurence, where dissection is passed
> to a heuristic dissector. In every case, NULL is passed as *data
> argument.

To be precise, in the *current* Wireshark source tree, NULL is passed as the *data argument in all calls to dissector_try_heuristic().

> So my question is this: What is the *data arguments intention

To allow the calling dissector to pass private information to the called dissector, rather than using the pinfo->private_data variable; that way, you don't have to worry about, for example, saving and restoring private_data values.  (It replaces a quasi-global variable with an argument.)

> and who uses it actually?

No heuristic dissectors currently use it, but it's there for use in the future; we may convert heuristic dissectors to use it in the future.

> But from a software development point of view, this is faulty
> behaviour. If we do have an argument we should use it or throw it
> away.

In places where arbitrary functions can be registered in tables, or passed as callback routines, the function signature is fixed, but not all functions necessarily have a use for all the information passed to them, even if some functions do.