Обсуждение: unknown conversion %m
All or almost all the warnings seen on Windows/Mingw of the type "warning: unknown conversion type character 'm' in format" come from checking of three functions: errmsg, elog and errdetail. I therefore propose to disable the attribute checking of those three functions, on Windows only (since that's the only place I've seen the warnings). That's a much more conservative change than I made previously which would have turned off all format warnings on Mingw, and along with fixing the INT64_FORMAT (see email just sent) would fix the vast majority of compiler warnings, so we'd be almost clean again on MinGW. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> All or almost all the warnings seen on Windows/Mingw of the type
> "warning: unknown conversion type character 'm' in format" come from
> checking of three functions: errmsg, elog and errdetail. I therefore
> propose to disable the attribute checking of those three functions, on
> Windows only (since that's the only place I've seen the warnings).
> That's a much more conservative change than I made previously which
> would have turned off all format warnings on Mingw, and along with
> fixing the INT64_FORMAT (see email just sent) would fix the vast
> majority of compiler warnings, so we'd be almost clean again on MinGW.
That seems to me to be throwing the baby out with the bathwater.
If Windows could be assumed to be just like every other platform,
we could maybe figure that being format-warning-free elsewhere
was sufficient checking; but that assumption is obviously wrong.
regards, tom lane
On 04/27/2011 12:50 AM, Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.net> writes: >> All or almost all the warnings seen on Windows/Mingw of the type >> "warning: unknown conversion type character 'm' in format" come from >> checking of three functions: errmsg, elog and errdetail. I therefore >> propose to disable the attribute checking of those three functions, on >> Windows only (since that's the only place I've seen the warnings). >> That's a much more conservative change than I made previously which >> would have turned off all format warnings on Mingw, and along with >> fixing the INT64_FORMAT (see email just sent) would fix the vast >> majority of compiler warnings, so we'd be almost clean again on MinGW. > That seems to me to be throwing the baby out with the bathwater. > If Windows could be assumed to be just like every other platform, > we could maybe figure that being format-warning-free elsewhere > was sufficient checking; but that assumption is obviously wrong. > > We're not doing anything about the warnings, and I'm not sure there's anything we can do other than suppress them or live with them. The compiler is in fact quite correct, it doesn't know anything about "%m", and if we were ever to use %m in a context where we actually expected it to output the contents of strerror(errno) the warning would be lost among a huge pile of these other warnings where its use is harmless because we expand it ourselves. That strikes me as a more potent danger. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> On 04/27/2011 12:50 AM, Tom Lane wrote:
>> Andrew Dunstan<andrew@dunslane.net> writes:
>>> All or almost all the warnings seen on Windows/Mingw of the type
>>> "warning: unknown conversion type character 'm' in format" come from
>>> checking of three functions: errmsg, elog and errdetail. I therefore
>>> propose to disable the attribute checking of those three functions, on
>>> Windows only (since that's the only place I've seen the warnings).
>> That seems to me to be throwing the baby out with the bathwater.
>> If Windows could be assumed to be just like every other platform,
>> we could maybe figure that being format-warning-free elsewhere
>> was sufficient checking; but that assumption is obviously wrong.
> We're not doing anything about the warnings, and I'm not sure there's
> anything we can do other than suppress them or live with them.
> The compiler is in fact quite correct, it doesn't know anything about
> "%m", and if we were ever to use %m in a context where we actually
> expected it to output the contents of strerror(errno) the warning would
> be lost among a huge pile of these other warnings where its use is
> harmless because we expand it ourselves. That strikes me as a more
> potent danger.
I don't buy that. The risk that gcc will let past a '%m' without
complaint, in a function that doesn't actually support it, exists on
most non-Linux platforms (ie pretty much anywhere you use gcc with
non-GNU libc), and has existed from the beginning. Despite this,
I cannot recall that we have ever had a bug of that ilk. But we have
most certainly had bugs with incorrect/unportable matching of other
format arguments. I think losing the ability to detect the latter
in Windows-specific code is a terrible price to pay for silencing
an easily-ignorable class of warnings.
regards, tom lane
On 04/27/2011 10:29 AM, Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.net> writes: >> On 04/27/2011 12:50 AM, Tom Lane wrote: >>> Andrew Dunstan<andrew@dunslane.net> writes: >>>> All or almost all the warnings seen on Windows/Mingw of the type >>>> "warning: unknown conversion type character 'm' in format" come from >>>> checking of three functions: errmsg, elog and errdetail. I therefore >>>> propose to disable the attribute checking of those three functions, on >>>> Windows only (since that's the only place I've seen the warnings). >>> That seems to me to be throwing the baby out with the bathwater. >>> If Windows could be assumed to be just like every other platform, >>> we could maybe figure that being format-warning-free elsewhere >>> was sufficient checking; but that assumption is obviously wrong. >> We're not doing anything about the warnings, and I'm not sure there's >> anything we can do other than suppress them or live with them. >> The compiler is in fact quite correct, it doesn't know anything about >> "%m", and if we were ever to use %m in a context where we actually >> expected it to output the contents of strerror(errno) the warning would >> be lost among a huge pile of these other warnings where its use is >> harmless because we expand it ourselves. That strikes me as a more >> potent danger. > I don't buy that. The risk that gcc will let past a '%m' without > complaint, in a function that doesn't actually support it, exists on > most non-Linux platforms (ie pretty much anywhere you use gcc with > non-GNU libc), and has existed from the beginning. Despite this, > I cannot recall that we have ever had a bug of that ilk. But we have > most certainly had bugs with incorrect/unportable matching of other > format arguments. I think losing the ability to detect the latter > in Windows-specific code is a terrible price to pay for silencing > an easily-ignorable class of warnings. > > What I'd like to know is why it doesn't complain elsewhere. The one non-Linux non-Windows machine I have is FBSD. Its gcc (4.2.1) doesn't expand "%m" but doesn't complain about it either. It does complain about other unknown formats. I wonder if they have patched gcc to silence the warnings? cheers andrew
Andrew Dunstan <andrew@dunslane.net> wrote: > What I'd like to know is why it doesn't complain elsewhere. It appears to be allowed as an "extension" on some compliers. http://sourceware.org/ml/newlib/2006/msg00079.html -Kevin
Andrew Dunstan <andrew@dunslane.net> writes:
> What I'd like to know is why it doesn't complain elsewhere.
That question is backwards ...
> The one
> non-Linux non-Windows machine I have is FBSD. Its gcc (4.2.1) doesn't
> expand "%m" but doesn't complain about it either.
It's libc, not gcc, that's actually got the responsibility of processing
format specifiers at runtime. gcc just assumes a particular behavior of
libc. I quote from the gcc 4.4.5 manual, under -Wformat:
The formats are checked against the format features supported by GNU libc version 2.2. These include all ISO
C90and C99 features, as well as features from the Single Unix Specification and some BSD and GNU extensions.
Otherlibrary implementations may not support all these features; GCC does not support warning about features that
gobeyond a particular library's limitations.
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.
regards, tom lane
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. cheers andrew
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
Andrew Dunstan <andrew@dunslane.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
On 04/28/2011 12:15 AM, Tom Lane wrote: > > 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. > > Yeah. In fact, if I adjust most of the format specs to gnu_printf I now get exactly five warnings on MinGW64 (down from about 600). All the 64 bit int format warnings and their cascaded effects dissolve, along with the %m warnings. What I'm thinking of doing is to set up something like: #define PG_PRINTF_CHECK __printf__ and on Windows redefine it to __gnu_printf__, and then set all the formats to use PG_PRINTF_CHECK. Sound OK? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> What I'm thinking of doing is to set up something like:
> #define PG_PRINTF_CHECK __printf__
> and on Windows redefine it to __gnu_printf__, and then set all the
> formats to use PG_PRINTF_CHECK.
> Sound OK?
+1 ... those __attribute__ declarations are messy enough already
without wrapping #ifdefs around them. (Don't want to find out
what pgindent would do with that ...)
Possibly PG_PRINTF_ATTRIBUTE would be a better name, but he who
does the work gets to pick.
regards, tom lane
Andrew Dunstan <andrew@dunslane.net> writes:
> What I'm thinking of doing is to set up something like:
> #define PG_PRINTF_CHECK __printf__
BTW, gcc 2.95.3 documents "printf", and not "__printf__".
Suggest not including the underscores, since that's apparently a
johnny-come-lately spelling. It's not like any of this construct
is even faintly portable to non-gcc compilers anyway ...
regards, tom lane
On 04/28/2011 12:44 AM, Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.net> writes: >> What I'm thinking of doing is to set up something like: >> #define PG_PRINTF_CHECK __printf__ > BTW, gcc 2.95.3 documents "printf", and not "__printf__". > Suggest not including the underscores, since that's apparently a > johnny-come-lately spelling. It's not like any of this construct > is even faintly portable to non-gcc compilers anyway ... > Yeah, I think that the underscore variants got added because of cases like ours where printf is sometimes defined as a macro. I'll just need to make sure that this gets set before there's any possibility of that happening. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Yeah, I think that the underscore variants got added because of cases
> like ours where printf is sometimes defined as a macro. I'll just need
> to make sure that this gets set before there's any possibility of that
> happening.
The existing code would already be broken if that were the case,
so I see no need to worry.
regards, tom lane
On 04/28/2011 12:30 AM, Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.net> writes: >> What I'm thinking of doing is to set up something like: >> #define PG_PRINTF_CHECK __printf__ >> and on Windows redefine it to __gnu_printf__, and then set all the >> formats to use PG_PRINTF_CHECK. >> Sound OK? > +1 ... those __attribute__ declarations are messy enough already > without wrapping #ifdefs around them. (Don't want to find out > what pgindent would do with that ...) > > Possibly PG_PRINTF_ATTRIBUTE would be a better name, but he who > does the work gets to pick. Done with that name. FYI, here is the complete set of warnings now generated on pitta: scan.c:16256:23: warning: unused variable 'yyg' c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql/src/backend/port/win32/mingwcompat.c:60:1: warning: 'RegisterWaitForSingleObject'redeclared without dllimport attribute: previous dllimport ignored c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql/src/backend/postmaster/postmaster.c:3305:2: warning: format'%d' expects type 'int', but argument 3 has type 'pgsocket' c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql/src/backend/postmaster/postmaster.c:4810:4: warning: format'%d' expects type 'int', but argument 2 has type 'SOCKET' c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql/src/backend/postmaster/syslogger.c:636:3: warning: format'%ld' expects type 'long int', but argument 4 has type 'intptr_t' c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c:505:6: warning:unknown conversion type character 'G' in format c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c:685:6: warning:unknown conversion type character 'V' in format cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Done with that name. FYI, here is the complete set of warnings now
> generated on pitta:
The "unused variable" is flex's fault, not much we can do about that.
Seems like most of the others could be removed with some explicit casting.
>
c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c:505:6:
> warning: unknown conversion type character 'G' in format
>
c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c:685:6:
> warning: unknown conversion type character 'V' in format
These are a bit interesting. According to the Single Unix Spec, %V
has been standard for strftime since at least 1997, so it's damn odd
if MS' version doesn't support that. OTOH, %G is *not* in that standard
... should we try to avoid using that?
But it looks like all those cases are only reached if the ecpg-using
application tries to use those formats, so maybe any portability risks
there aren't our problem. Maybe a reasonable fix is the one that's
already there for %g, ie, just prevent the gcc check from occurring.
regards, tom lane
On 04/28/2011 12:41 PM, Tom Lane wrote: > >> c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c:505:6: >> warning: unknown conversion type character 'G' in format >> c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.3240/../pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c:685:6: >> warning: unknown conversion type character 'V' in format > These are a bit interesting. According to the Single Unix Spec, %V > has been standard for strftime since at least 1997, so it's damn odd > if MS' version doesn't support that. OTOH, %G is *not* in that standard > ... should we try to avoid using that? > > But it looks like all those cases are only reached if the ecpg-using > application tries to use those formats, so maybe any portability risks > there aren't our problem. Maybe a reasonable fix is the one that's > already there for %g, ie, just prevent the gcc check from occurring. > > I'll make that change if Michael's happy. cheers andrew
> I'll make that change if Michael's happy. Sure, go ahead. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
On Thu, Apr 28, 2011 at 02:49:07PM -0400, Andrew Dunstan wrote: > I'll make that change if Michael's happy. Sure, go ahead. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL