Wireshark-bugs: [Wireshark-bugs] [Bug 3534] IETF ForCES(Forwarding and Control Element Separatio
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3534
--- Comment #16 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2012-09-06 12:14:50 PDT ---
(In reply to comment #15)
> (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)
[This discussion might be better suited for the -dev list.]
Yes, the tree==NULL check is for faster processing. Some people care very much
about speed [probably because they often work with larger files]. Wireshark
with no coloring rules (how I normally work) or tshark (without "-V") both
stand to benefit from if(tree) checks.
But it's all a question of effort vs. reward. If you've got a function with
100 proto_tree_add_item()s that don't affect the columns or expert info then
you could easily trade one if(tree) for 100 function calls which then end up
taking the shortcut out when tree==NULL. OTOH if you've got column updates and
expert infos hiding in there (or if you're tracking the offset into the tvb)
then you're probably better off without the if(tree) check.
--
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.
