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.