Wireshark-bugs: [Wireshark-bugs] [Bug 3534] IETF ForCES(Forwarding and Control Element Separatio
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3534
--- Comment #15 from Michael Mann <mmann78@xxxxxxxxxxxx> 2012-09-06 06:11:22 PDT ---
(In reply to comment #14)
> So checking for tree == NULL, and not setting column info/expert is mostly ok
> in wireshark, in other application using libwireshark it might be not.
> AFAIK we care about other applications, quoting README.developer:
> "Note, however, that you must fill in column information, (...)
> do calls to "expert" functions, (...) regardless of whether 'tree'
>
> I'd rather remove tree == NULL check, but it's your patch.
So why ever have the tree == NULL check? I have noticed certain dissectors
seem to cater more towards Wireshark or tshark (whichever the developer is more
used to) in how "fields" are populated (with some, IMO overpopulating the
COL_INFO column for example). While it may be my patch, I would like its use
to be maximized.
To me the tree == NULL check is for faster processing (Wireshark only?). If I
have to dissect the protocol for column info, "expert" functions, etc, I'm not
saving much processing time (because the fields have to be dissected anyway for
those items). And the code would be unnecessarily ugly with more tree == NULL
checks sprinkled about the code to avoid missing column info, "expert"
functions, etc. For "simple" protocols like this one, I thought it was common
practice to put the tree == NULL near the top of the protocol dissection (but
maybe it should be just after the setting column info)
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
