Comment # 6
on bug 6357
from Hadriel Kaplan
(In reply to comment #5)
[note: I'm pretty sure you know all this far better than I do, but I'm having
trouble grokking what you mean exactly, so I'll try to be thorough to make sure
we're on the same page]
> That sounds like a bug. "Visible" in the GUI sense should only govern
> whether the field shows up in the packet-details pane and in text output
> from "tshark -V" and "Export Packet Dissection -> As "Plain Text" file" and
> "...As "Postscript" file". Fields that are "visible" in the GUI sense may
> have to be put into the protocol tree, but "invisible" fields (e.g.,
> ip.addr) need at least to be available for "-e" and "...As XML - "PDML"
> (Packet details) file".
Yes but in the 'tshark -e' case tshark does set the full proto_tree to be
visible when dissecting the packets; it just filters the output to only be what
the user specified for the fields afterwards while printing.
(Arguably it could have done it another way, creating a dfilter for the fields
the user wanted, which would be better performance, but that's not how it's
implemented currently)
> In addition, "visible", at least for "tshark -V" and "...As "Plain Text"
> file" and "...As "Postscript" file", requires that the "representation",
> i.e. what's displayed to users, be filled in, but just getting the *value*
> doesn't.
I think you mean the string-ified pretty-representation of the value only needs
to be populated when things are going to be visible, but getting the raw value
of the field should be possible anytime and thus the value should always be
populated?
Right now that's not the case - with the TRY_TO_FAKE_THIS_ITEM optimization,
the raw values are not populated unless the field is "interesting" to something
at the time it's dissected. In the case of the proto_tree being set to
'visible', every field is interesting. If a dfilter is used due to a color
filter, display filter, etc., then the fields in the dfilter are interesting.
If a field is interesting, then its value is populated. But I believe the
pretty-string is created later during display by something that gets the value
and string-ifies it based on its type. (though I could be wrong about that)
It's not just the value that isn't populated: the whole field_info struct isn't
malloc'ed and filled in for that field. (well, "malloc" is the wrong word since
it's allocated from emem) So the performance boost from the
TRY_TO_FAKE_THIS_ITEM optimization is probably significant.
> So perhaps "visible" controls too much, and there should be more than one
> attribute to control what's populated.
I think it's more that the word "visible" is misleading in this case - the
epan_dissect_init() argument's name is 'proto_tree_visible' and ultimately it
sets a gboolean named 'visibile' in the proto_tree, but basically it's used
just to mean "populate all field_infos during dissection". They won't be
stringified into a pretty-string representation by setting this, and won't
become suddenly displayed somewhere if they weren't already.
You are receiving this mail because:
- You are watching all bug changes.
