Andrew Dunstan <andrew@dunslane.net> writes:
> OK, having gone a long way down this hole, I think I have the answer.
> Using an attribute of 'gnu_printf' instead of just 'printf' on the
> elog.h functions clears all those warnings.
> The manual at
> <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes>
> says:
> The parameter archetype determines how the format string is
> interpreted, and should be printf, scanf, strftime, gnu_printf,
> gnu_scanf, gnu_strftime or strfmon. (You can also use __printf__,
> __scanf__, __strftime__ or __strfmon__.) On MinGW targets,
> ms_printf, ms_scanf, and ms_strftime are also present. archtype
> values such as printf refer to the formats accepted by the system's
> C run-time library, while gnu_ values always refer to the formats
> accepted by the GNU C Library.
Hmm, interesting. I see gnu_printf also documented in the gcc 4.4.5
manual on my Fedora 13 machine (so it's not something specific to mingw)
but it's not present on my ancient 2.95.3 gcc, so I'm not too sure when
it was introduced.
I'd suggest adjusting the elog.h declarations to use gnu_printf only on
Windows, and printf elsewhere, for the moment. Maybe we can migrate
towards using gnu_printf on other platforms later.
regards, tom lane