Wireshark-dev: Re: [Wireshark-dev] why does dissector_try_uint_new() return gboolean?
From: Guy Harris <[email protected]>
Date: Tue, 24 Jul 2012 22:55:28 -0700
On Jul 24, 2012, at 5:02 AM, Martin Kaiser wrote:

> Would it make sense to change dissector_try_uint_new() to return guint?

Bear in mind that there are some cases where a dissector can successfully dissect a packet with zero bytes of data, so overloading an "amount dissected" return value to also indicate, with a return value of 0, that the packet isn't for the protocol in question, doesn't work.

Consider a case where you have:

	protocol A, which has "request" and "response" packets, with a "request" packet containing a request ID and a "response" packet containing the request ID of the corresponding request and a reply status, with both protocols followed by payload for

	protocol B, which gives the details of the requests and responses.

An error response to a request might just contain a reply code indicating the type of error.

I forget which protocols were involved, but I ran into a situation such as that when I tried that many years ago; I could see if I can dig it up.

> Should I leave dissector_try_uint_new() as it is and introduce a similar
> function returning guint?

One possibility might be to:

	introduce a new type of dissector, which is handed a ptvcursor instead of a tvbuff, and which returns a gboolean that's TRUE if the packet is for the dissector and FALSE if not;

	have a routine to register *that* type of dissector and return a dissector_handle_t;

	have new variants of call_dissector(), call_dissector_only(), dissector_try_uint(), dissector_try_string(), etc. that take a ptvcursor instead of a tvbuff and return a gboolean;

	in the calls that take a tvbuff as an argument, when calling a dissector that expects a ptvcursor, construct a ptvcursor from the tvbuff, hand it to the dissector, and:

		if the dissector returns FALSE, return 0;

		if the dissector returns TRUE, return the difference between where the ptvcursor started and where it ended;

	in the calls that take a ptvcursor as an argument, when calling a dissector that expects a tvbuff, construct a tvbuff if necessary (i.e., if the offset in the ptvcursor is non-zero), hand that to the dissector, and:

		if it's an "old-style" dissector not returning anything, advance the ptvcursor to the end of the captured data in the tvbuff and return TRUE;

		if it's a "new-style" dissector returning a guint, advance the ptvcursor using the return value and:

			if the dissector returns 0, return FALSE;

			if the dissector returns a non-zero value, return TRUE;

and, for those dissectors that need to return "amount dissected" *and* "is this my packet" indications, make them "new new style" dissectors taking a ptvcursor as an argument.