Ethereal-dev: Re: [ethereal-dev] Surely, I missed something...
On Fri, Aug 18, 2000 at 06:24:37PM +0200, Laurent Deniel wrote:
> Now we have many proto_tree_add_xxx[_{hidden,format}] routines which
> allow to easily control the field display.
...and also lets the compiler check to make sure you're not, say,
passing in a pointer as the value for an integral, Boolean, or
enumerated field, or passing in an integral value as the value for a
string or byte array. (Adding in the "proto_tree_add_xxx()" routines
caught some of those....)
> Good. But what I do not
> understand is the usage (in many dissectors) of a specific
> proto_tree_add_xxx routine (said add_boolean) if in the registration
> process we already know the type (i.e. FT_BOOLEAN), why not using
> proto_tree_add_item in that case ?
Because "proto_tree_add_item()" requires a non-null tvbuff, so it's
usable only in "new-style" dissectors.
I suspect we could add "old_proto_tree_add_item()", for non-tvbuffified
dissectors, taking the "pd" value as an argument, if that's desired.
If the dissector uses tvbuffs, and the value to be added to the protocol
tree can be properly extracted from the tvbuff by
"proto_tree_add_item()", I can't think of any reason not to use
"proto_tree_add_item()" rather than "proto_tree_add_xxx()" (and the same
applies to the hidden variants), and don't have a problem with changing
those calls.
There's no "proto_tree_add_item_format()" because I suspected you'd have
to fetch the value from the tree *anyway* in order to pass it - or some
transformation of it - as an argument to the format, so I figured you
might as well just add the extracted value with a "proto_tree_add_xxx()"
call, but it might be that "proto_tree_add_item_format()" would still be
useful for other reasons - if so, we can probably add it.
"proto_tree_add_xxx()" would, even in tvbuffified dissectors, be useful
if the value to be inserted into the protocol tree *isn't* just
extracted from the packet, e.g. an FT_ABSOLUTE_TIME value that's stored
in the packet as something other than a UNIX-style seconds/microseconds
timeval.
(BTW, should we make FT_ABSOLUTE_TIME and FT_RELATIVE_TIME be
seconds/nanoseconds rather than seconds/microseconds?
seconds/microseconds can be easily turned into seconds/nanoseconds,
without loss of data, but turning seconds/nanoseconds into
seconds/microseconds *does* lose some precision.)
> and what happens if we do a
> proto_tree_add_xxx on an hfinfo item field of type FT_YYY ?
The program dies with an assertion failure; for example,
"proto_tree_add_boolean()" has a
g_assert(hfinfo->type == FT_BOOLEAN);
call in it.
> Could you tell me also if some of them are not intended to work with a
> NULL tvbuff ? the ones that do not have the value in argument, I think ?
The ones that don't have the value in the argument won't work with a
null tvbuff, as per the above.
> PS: I hate to have to change many plugins in order to use the correct
> add_xxx call according to the field type (add_item was better :-),
> or would it be simpler to use tvbuff ??
The *simplest* solution would probably be to add
"old_proto_tree_add_item()", as per the above, as that doesn't involve
tvbuffifying the plugins and changing the plugin interface to handle
tvbuffs.
The right *long-term* solution is to tvbuffify the plugin interface and
the plugins, but we don't necessarily have to take the long-term
solution right now.
