Thomas Munro <thomas.mu...@enterprisedb.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