Andreas <andreassand...@...> 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. */ ___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe
