> (The problem was a call to "proto_tree_add_text()" with an argument list
> that didn't match the format; GCC didn't catch that because
> "proto_tree_add_text()" wasn't, when compiled with GCC, declared with an
> "__attribute__((format (printf, ...))" clause - doing that is tricky, as
> "_proto_tree_add_item_value()"'s first "varargs" argument is *not* a
> format string, so I'll have to look into seeing if that can be done,
> i.e. if the first argument number in said clause has to refer to a
> declared argument.
The first argument in said clause has to refer to a declared argument.
Oh, well.
Having a function that has a variable argument list, where one of the
arguments in the variable part of the argument list is a "printf"-style
function string and subsequent arguments are values to apply to that
string, apparently doesn't let you do format-string checking; the format
string has to be part of the *fixed* portion of the argument list, with
the values to apply to that string immediately following it.
I.e., to make it work, "proto_tree_add_text()" must be
proto_item *
proto_tree_add_text(proto_tree *tree, gint start, gint length,
const char *format, ...)
{
...
}
Unfortunately, this means it can't easily call
"_proto_tree_add_item_value()"....
Perhaps, instead of a single "_proto_tree_add_item_value()" routine,
there should be multiple such routines, with the value being part of the
*fixed* portion of the argument list. This would also let us do the
same with "proto_tree_add_item()" and the like, which would not only let
us do format checking on "proto_tree_add_item_format()", it would *also*
let us catch some incorrect calls to the various "proto_tree_add_item"
routines, e.g. passing a pointer if the actual item is of an integral
type.
Yes, this complicates some things - but I'm beginning to suspect, given
the number of errors I've found in calls to "proto_tree_add_text()"
(bear in mind that I've only checked in fixes for *some* of the ones
I've found, so there's more to come...), that we'd be better off for it,
even with the added complications. It's almost always better to get a
compiler error than a run-time error....