Wireshark mailing list archives
Re: why does dissector_try_uint_new() return gboolean?
From: Guy Harris <guy () alum mit edu>
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. ___________________________________________________________________________ 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
Current thread:
- why does dissector_try_uint_new() return gboolean? Martin Kaiser (Jul 24)
- Re: why does dissector_try_uint_new() return gboolean? Guy Harris (Jul 24)
- Re: why does dissector_try_uint_new() return gboolean? Martin Kaiser (Jul 26)
- Re: why does dissector_try_uint_new() return gboolean? Guy Harris (Jul 24)