Re: c/1027: slightly misleading printf format warning

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: "Joseph S. Myers" <jsm28@cam.ac.uk>
 > 
 > On Sun, 10 Dec 2000, Kaveh R. Ghazi wrote:
 > 
 > > IMHO, we should see if there is a solution which doesn't do this.  Or
 > > better yet, implement the "extensible format checking" from the
 > > projects page. :-)
 > 
 > Care to suggest a syntax for specifying format conversions :-)?  In
 > particular, some change seems to be needed to both the C and C++ grammars
 > to implement format specifications - at least if it is to be possible to
 > pass types (such as "tree") in, which is fairly important.  Also, I don't
 > want to end up with a syntax too closely bound to GCC's internal data
 > structures at the time it was implemented.

I haven't put too much thought into it, but it seems to me that we
need a way to specify the following:

1.  Each new specifier character.
2.  A "type" accepted by each new specifier.
3.  Some way to indicate whether we start with the existing printf and
    add the extensions or start from scratch
4.  Optionally allow some way to specify whether modifiers are allowed
    in between the % and the specifier character and how to validate
    them.

E.g. for 1 & 2 we do:
__attribute__ ((__format__ (__printf__, m, n) (__specifier__, T, tree)))

(Note this requires typedef "tree" to be visible whenever the
attribute is used.)

I haven't thought through all the ramifications and we'll obviously
want to design it well before putting something out there or we'll end
up supporting junk for eternity. :-)

The ideal grammer is to come up with something that allows you to
specify everything in the current attribute printf.  But that might be
too hard.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions