Maybe I should avoid making suggestions that would make the project
more complex, especially since I'm not implementing it, but...
If we can describe the argument types expected for a given format
string, then we can produce warnings for values used but not yet set
(%s with an uninitialized automatic char array, but not %n with an
uninitialized int), and let the compiler know what values are set by
the call for use in later warnings. For additions like bfd's %A and %
B, though, we'd need a way of indicating what fields of the pointed-
to structure are read and/or written, because some of them may be
ignored, or only conditionally used.
Seems to me the best way to describe that is either calling out to
user-supplied C code, or providing something very much like a C
function or function fragment to show the compiler how the parameters
are used -- off the top of my head, say, map 'A' to a static function
format_asection which takes an asection* argument and reads the name
field, which function can be analyzed for data usage patterns and
whether it handles a null pointer, but which probably would be
discarded by the compiler. Mapping format specifiers to code
fragments might also allow the compiler to transform
bfd_print("%d:%A",sec,num)
to
printf("%d:%s",num,sec->name)
if it had enough information. But that requires expressing not just
the data i/o pattern, but what the formatting actually will be for a
specifier, which sometimes may be too complex to want to express.
Just a thought...
Ken