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

Reply via email to