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