ronnie sahlberg wrote:
On 12/2/05, Harms, Kyle J <Kyle.J.Harms@xxxxxxxxxx> wrote:
2,
README.developer does not mention anything about a new style dissector.
Where might I look at an example of such a dissector? I might suggest
that the README.developer stub be updated to be a new style dissector.
Ok, remind me i must update that.
...although the *current* form of new-style dissector has some problems:
1) it can't distinguish between "the tvbuff we were handed had zero
bytes in it" and "the tvbuff we were handed wasn't a packet for my
protocol" - and, yes, there are some cases where this makes a difference.
2) having to return the amount of data dissected is more work than is
necessary just to return an accepted/rejected indication - but there are
some places where the calling dissector really *does* need to know how
much was dissected.
That's why I haven't just converted all dissectors to new-style ones and
renamed new_create_dissector_handle(), etc. to create_dissector_handle().
If dissectors were handed a ptvcursor, and returned TRUE or FALSE,
that'd handle some of that, but it'd still mean that the dissector
should advance the ptvcursor regardless of whether it does a full
dissection or not. Given that dissectors often don't work correctly
when *not* doing a full dissection (i.e., when passed a null protocol
tree pointer), because they skip some offset-advancing or
subdissector-calling (or possibly other operations) when the tree
pointer is null, perhaps we should discourage checking whether the
protocol tree pointer is null, even if that does mean dissectors do more
work than is necessary.