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
printfrefer 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
