Re: C++ error printer cleanup, phase 1

[Zack Weinberg <zack at codesourcery dot com>]

On Mon, Sep 24, 2001 at 06:41:20AM +0100, Joseph S. Myers wrote:
> 
> 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.

Yeah, you're right, I was handwaving over a lot of the difficulties.
And it would be tidier to start from scratch for the diagnostic
printf-alike, which _is_ a lot simpler.

My point was that we don't have to do a perfect description of the
format syntax and semantics, in order to get something which is good
enough to do basic type checking, which is the important bit.

> 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 is where I admit to not having read through c-format.c at all.
I'll push that onto the to-do-eventually stack...

> 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.

There's a common subset which is safe in the back end, and then each
front end has the opportunity to add its own set of extensions.
Rather than adding more #defines I would prefer to control it with
additional declarations: the back end sees only the basic "this is
kinda like printf" from toplev.h; the front end gets that and then
another decl from one of its own header files, describing its own
extensions.

zw