Andreas <AndreasSander1@...> writes:
> So it looks like that it is bad practice to check for tree==NULL. The
> proto_tree_add_... functions will check for tree==NULL by itself. The
> delayed dissection was done for improved speed. ;-(
Well, it's not bad practice per se, but it does require some careful
consideration. This is addressed in the comments within the skeleton code
provided in section 1.2 of README.developer as follows:
In the interest of speed, if "tree" is NULL, avoid building a
protocol tree and adding stuff to it, or even looking at any packet
data needed only if you're building the protocol tree, if possible.
Note, however, that you must fill in column information, create
conversations, reassemble packets, build any other persistent state
needed for dissection, and call subdissectors regardless of whether
"tree" is NULL or not. This might be inconvenient to do without
doing most of the dissection work; the routines for adding items to
the protocol tree can be passed a null protocol tree pointer, in
which case they'll return a null item pointer, and
"proto_item_add_subtree()" returns a null tree pointer if passed a
null item pointer, so, if you're careful not to dereference any null
tree or item pointers, you can accomplish this by doing all the
dissection work. This might not be as efficient as skipping that
work if you're not building a protocol tree, but if the code would
have a lot of tests whether "tree" is null if you skipped that work,
you might still be better off just doing all that work regardless of
whether "tree" is null or not.
Note also that there is no guarantee, the first time the dissector is
called, whether "tree" will be null or not; your dissector must work
correctly, building or updating whatever state information is
necessary, in either case. */
