Re: Allowing printf("%m") only where it actually works

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> I tried this on macOS and FreeBSD using GCC and Clang: both accept
> printf("%m") without warning and then just print out "m". It'll be
> interesting to see if the NetBSD patch/idea travels further or some
> other solution can be found. I've raised this on the freebsd-hackers
> list, let's see... I bet there's other software out there that just
> prints out "m" when things go wrong. It's arguably something that
> you'd want the complier to understand as a C dialect thing.

Yeah. ISTM that the netbsd guys didn't get this quite right. The
gcc docs are perfectly clear about what they think the semantics should
be:

The parameter archetype determines how the format string is
interpreted, and should be printf, scanf, strftime, gnu_printf,
gnu_scanf, gnu_strftime or strfmon. ... archetype values such as
printf refer to the formats accepted by the system’s C runtime
library, while values prefixed with ‘gnu_’ always refer to the formats
accepted by the GNU C Library.

Therefore, what netbsd should have done was leave the semantics of
"gnu_printf" alone (because glibc undoubtedly does take %m), and just emit
a warning with the "printf" archetype --- which is supposed to describe
the behavior of the platform's stdio, which in their case is known not
to take %m. If they'd done it that way then they'd have a patch that gcc
upstream certainly ought to accept, because it follows gcc's own stated
semantics for the check. This would also partially resolve the complaint
Roy Marples had in the thread I alluded to, ie he could use "gnu_printf"
to describe a function that accepts %m. (There might still need to be
some work to be done to avoid bogus -Wmissing-format-attribute complaints,
not sure.) I'm not sure whether a separate archetype for syslog is really
needed. Formally you could say that distinguishing syslog from GNU printf
is wise, but I'm not sure I see a practical need for it.

regards, tom lane