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 <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
