> <aside>
> Of course, I never really like proto_tree_add_item_format, because
> I feel that everything should be generic enough to use
> proto_tree_add_item(). That's a lofty goal, but one we have to consider
> when we start moving towards libdencode, where Ethereal will just take
> the decode data from libdencode and displays it in the GUI.
> </aside>
I suspect that it would be too stringent a constraint on the format of
the tree items to get rid of "proto_tree_add_item_format()".
One *could* have, as one of the properties of a field, a pointer to a
formatting routine - if it's NULL, the standard "proto_tree_add_item()"
formatting would be used, otherwise the routine will be called with a
pointer to the item and expected to fill in the item's text
appropriately.
If we went that way, we *could* nuke "proto_tree_add_item_format()". We
would, of course, then want to have "proto_tree_add_text()" declared
with "__attribute(format (printf, N, N+1))", even thought it'd mean
"proto_tree_add_text()" couldn't call "_proto_tree_add_item_value()"
(because "_proto_tree_add_item_value()" takes the format as a "..."
argument rather than as an explicit argument).
> Idea #1
> =======
> Since the format and the args for that format usually go last in the
> argument list, the value of the field has to go before the format. So,
> we'll end up with lots of functions:
...but you can do run-time checking of the arguments, as per my comment.
However, "XXX_uint8", "XXX_uint16", "XXX_uint24", and "XXX_uint32" is
probably overkill - "XXX_uint" is probably sufficient, taking a
"guint32" argument. That means you don't get to check that the caller
isn't handing the wrong size of type, but that may not be necessary.
Then again, note that "proto_tree_add_item_format_uint8()" and so on
don't need a "length" argument, so that might be an argument in favor of
having different routines for each type.
Unfortunately, that'd get in the way of allowing dissectors to specify
their *own* item types (e.g., specifying a format routine to use, a
comparison or comparison routines to use for filtering, a routine to use
for "unformatting", i.e. taking a string from, say, a filter
expression, and converting it to a value of the type in question, and so
on) - we can't do that now, but I could imagine it might be useful.
> Idea #3
> =======
...
> Since this API is so non-standard, it might cause grief to programmers
> (but we'd find the problem at compile-time! :-)
Yeah, I thought of the same - but the non-standard API could be a bit of
a rude surprise.