Re: [PATCH]: Proof-of-concept for dynamic format checking

[Ken Raeburn <raeburn at raeburn dot org>]

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