Re: why does dissector_try_uint_new() return gboolean?

[Guy Harris <guy () alum mit edu>]

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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe