Re: unknown conversion %m

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