Michael Paquier <michael.paquier@gmail.com> writes:
> On Fri, May 23, 2014 at 10:43 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
>> c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/contrib/pg_stat_statements/pg_stat_statements.c: In
function'pgss_ProcessUtility':
>>
c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/contrib/pg_stat_statements/pg_stat_statements.c:998:4:
warning:unknown conversion type character 'l' in format [-Wformat=]
>> sscanf(completionTag, "COPY " UINT64_FORMAT, &rows) != 1)
>> ^
>>
c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/contrib/pg_stat_statements/pg_stat_statements.c:998:4:
warning:too many arguments for format [-Wformat-extra-args]
> Hm... After a little bit of googling, I found that:
> http://sourceforge.net/p/mingw/bugs/1315/
> This seems to be part of the standard of Microsoft, making sscanf not
> accept ISO-C99 format specifiers. Looking more into the code, this is
> a pretty old warning introduced by a5495cd of 2009. This code is btw
> correct as the number of rows returned by a COPY is uint64. Any idea
> what would be doable here?
Yeah, this is bad: sscanf is likely to make the wrong conclusion about the
width of "rows", resulting in returning garbage, on Windows. It seems
pretty brain-dead to me that mingw wouldn't make sure that printf and
scanf accept comparable format specifiers, but on the other hand,
brain-dead behavior seems to be the norm on that platform.
The mingw bug cited above recommends using the format macros defined
by <inttypes.h>; but that approach doesn't excite me, because those
macros are a relatively recent invention (I don't see them in SUS v2)
so relying on them could easily fail on other platforms.
The best alternative I can think of is to use strncmp() to check for
whether the head of the string matches "COPY ", and then perform the
integer conversion using strtoull() #ifdef HAVE_STRTOULL and strtoul()
otherwise.
regards, tom lane