On 04/27/2011 11:58 AM, Andrew Dunstan wrote:
On 04/27/2011 11:02 AM, Tom Lane wrote:
So the question to ask is not why gcc doesn't complain about %m
elsewhere, but why it does complain in your Windows installation.
I'm guessing that the mingw people hacked it. If you're lucky,
they might have hacked in an extra switch to control the behavior ---
I notice quite a few subsidiary switches that tweak -Wformat behavior
in standard gcc 4.4.5.
Hmm. The error disappears if I use -D__USE_MINGW_ANSI_STDIO=1 or -posix
I don't know what other effects that might have, though. There's a
description here:
<http://sourceforge.net/project/shownotes.php?release_id=24832> I'll
experiment and see what happens.
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.
I can confirm this works on my W64/Mingw machine.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
