[cfe-commits] [Patch] -Wformat-non-standard: warn about positional arguments (pr12017)

[Joerg Sonnenberger]

On Mon, Feb 27, 2012 at 05:56:26PM +0000, Hans Wennborg wrote:
> On Mon, Feb 27, 2012 at 16:54, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
> > On Mon, Feb 27, 2012 at 03:09:05PM +0000, Hans Wennborg wrote:
> >> The attached patch makes -Wformat-non-standard warn about the use of
> >> positional arguments (e.g. "%3$d") in format strings. (pr12017)
> >
> > It sounds wrong to use -Wformat-non-standard for those, since they are
> > covered by POSIX.
> 
> Looking at http://pubs.opengroup.org/onlinepubs/009695399/functions/printf.html,
> it seems that so are the 'S' and 'C' conversion specifiers.

Agreed.

> Do you have a better name suggestion for the flag?
> 
> The intention was that it should mean "non-standard" as in "non ISO C standard".

Can we come to an agreement for the intended behavior first before
talking about naming? I think there are two different but related
problems here:

(1) Tagging functions as supporting different variations of printf-like
format strings. Examples are standard printf(3), GNU printf(3) and syslog(3).

(2) Requesting format strings to be restricted to a standard subset.

One of the question is now if it should be possible to tag a function as
supporting a standard and extensions, independent of the "active"
standard subset. E.g. if I have a configure test that checks if
asprintf(3) supports all GNU extensions, I want to use the system
version and otherwise my custom replacement. I don't want clang to warn
about "unportable" format strings in this case, but I do want warnings
for all printf(3) calls. This means extending the format attribute.

The other problem is that portablity checks are not binary in this case.
At the very least for printf(3), C89 / C99 / POSIX / GNU are valid
subsets users can be interested in.

Joerg