Re: C++ error printer cleanup, phase 1

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Sun, 23 Sep 2001, Zack Weinberg wrote:

> extern void error(const char *msgid, ...)
> 	__attribute__ ((format(extend, ('T', tree),
> 				       ('L', enum languages),
> 				       /* ... */)));
> 
> Later, we can define additional tuple fields if we figure out how to
> express additional information.  The above is enough to handle
> everything that the C++ front end does right now, as long as the
> default is for the + and # modifiers to be acceptable on any such
> format letter.

However, this elides most of the problems.  Why those flags but not
others?  What about length modifiers?  What about width and precision?
Does the inclusion of 'L' imply the 'L' length modifier is no longer
available?  What about -pedantic?  Logically, you want to describe the
particular extension of a subset of printf features that the function
supports - there are plenty of features that GCC's format checking
understands but the diagnostic machinery doesn't.

(Whatever is done, some new syntax for __attribute__ is needed to pass the
type names in - and this syntax should preferably be reasonably simply and
easy to maintain in the parsers.)

> I'm not sure whether it is currently okay to declare a function twice
> with different attributes, and if it is, whether it has the desired
> effect (the attribute sets are unioned).  If not, a pragma might work
> instead:

The lists should be merged - and since table-driven attributes, this does
allow multiple attributes with the same name but different arguments.  
Once I've finished applying format attributes to types, each distinct one
will then get separately checked (so a function will be able to have
several printf and scanf attributes, although it won't make much sense for
more than one of them to use the variable arguments; and it will be able
to have several format_arg attributes, which makes sense for ngettext
which is already marked up thus in current glibc).

I'd expect that extensible format checking would allow you to declare a
new format type name that goes alongside printf, scanf, strftime and
strfmon - either starting from scratch or by copying the built-in tables
for one of those kinds of format.  That's why the current code avoids
explicit checks for given kinds of format, instead now entirely using the
various data structures of c-format.c (albeit with features only relevant
to one kind of format such as FMT_FLAG_SCANF_A_KLUDGE).

This implies that error would need to get the right format attribute for
the code using it (since multiple format attributes would mean multiple
checks).  I'd hope this could be done by something simple such as defining
IN_C_FRONT_END to get it declared with the extended format.

-- 
Joseph S. Myers
jsm28@cam.ac.uk