Re: [HACKERS] unknown conversion %m
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
On 04/28/2011 12:44 AM, Tom Lane wrote: Andrew Dunstanand...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
Andrew Dunstan and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
On 04/28/2011 12:30 AM, Tom Lane wrote: Andrew Dunstanand...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
Andrew Dunstan and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
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: mes...@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
On 04/27/2011 12:50 AM, Tom Lane wrote: Andrew Dunstanand...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
Andrew Dunstan and...@dunslane.net writes: On 04/27/2011 12:50 AM, Tom Lane wrote: Andrew Dunstanand...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
On 04/27/2011 10:29 AM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: On 04/27/2011 12:50 AM, Tom Lane wrote: Andrew Dunstanand...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
Andrew Dunstan and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
Andrew Dunstan and...@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 C90 and C99 features, as well as features from the Single Unix Specification and some BSD and GNU extensions. Other library implementations may not support all these features; GCC does not support warning about features that go beyond 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
Andrew Dunstan and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
Andrew Dunstan and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
Andrew Dunstan and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
Andrew Dunstan and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
