Re: unknown conversion %m

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unknown conversion %m
Date: 2011-04-28 04:15:11
Message-ID: 17721.1303964111@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sim Zacks 2011-04-28 04:17:38 Re: Proposal - asynchronous functions
Previous Message Tom Lane 2011-04-28 04:03:16 Re: make world fails