Re: [HACKERS] Re: popen and pclose redefinitions causing many warning in Windows build
On Fri, Jun 6, 2014 at 01:18:24PM -0400, Alvaro Herrera wrote: Bruce Momjian wrote: On Wed, May 28, 2014 at 12:29:28PM -0400, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: I think this is caused because the variable is not defined as SOCKET. The attached patch fixes this. This should prevent the warning. Surely that's just going to move the errors somewhere else. The call site still expects the argument to be int[]. Ah, yes, you are right. This is a similar problem I had with libpq where PQsocket() had to return an int. Attached is an updated patch which follows my previous coding of checking for PGINVALID_SOCKET, and if not equal, assigns the value to an integer handle. I would also like to rename variable 's' to 'listen_sock', but that is not in the patch, for clarity reasons. Should this be held for 9.5? I think it is only warning removal. On the other hand, portability is what we do during beta testing. I think this should go in 9.4, but as you say it's only warning removal so there is probably little point in patching further back (this code dates back to 9.3.) Agreed and applied. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- 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] Re: popen and pclose redefinitions causing many warning in Windows build
Bruce Momjian wrote: On Wed, May 28, 2014 at 12:29:28PM -0400, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: I think this is caused because the variable is not defined as SOCKET. The attached patch fixes this. This should prevent the warning. Surely that's just going to move the errors somewhere else. The call site still expects the argument to be int[]. Ah, yes, you are right. This is a similar problem I had with libpq where PQsocket() had to return an int. Attached is an updated patch which follows my previous coding of checking for PGINVALID_SOCKET, and if not equal, assigns the value to an integer handle. I would also like to rename variable 's' to 'listen_sock', but that is not in the patch, for clarity reasons. Should this be held for 9.5? I think it is only warning removal. On the other hand, portability is what we do during beta testing. I think this should go in 9.4, but as you say it's only warning removal so there is probably little point in patching further back (this code dates back to 9.3.) -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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] Re: popen and pclose redefinitions causing many warning in Windows build
On Mon, May 26, 2014 at 09:50:42PM +0900, Michael Paquier wrote:
x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-g -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/interfaces/libpq
-I../../../src/include
-I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include
-I../pgsql/src/include/port/win32 -DEXEC_BACKEND
-I/c/prog/3p64/include/libxml2 -I/c/prog/3p64/include
-I/c/prog/3p64/openssl/include
-I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include/port/win32
-c -o parallel.o
/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c
c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c:
In function 'pgpipe':
c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c:1332:2:
warning: overflow in implicit constant conversion [-Woverflow]
handles[0] = handles[1] = INVALID_SOCKET;
^
c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c:1386:3:
warning: overflow in implicit constant conversion [-Woverflow]
handles[1] = INVALID_SOCKET;
^
In mingw-w64, SOCKET_INVALID is defined as ~0:
http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/psdk_inc/_socket_types.h
Is this overflow caused because SOCKET_INVALID corresponds to a 64b
value in mingw-w64?
Looking at the code this exists since 9.3.
I think this is caused because the variable is not defined as SOCKET.
The attached patch fixes this. This should prevent the warning.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/src/bin/pg_dump/parallel.c b/src/bin/pg_dump/parallel.c
new file mode 100644
index caedbb8..cd6ef7a
*** a/src/bin/pg_dump/parallel.c
--- b/src/bin/pg_dump/parallel.c
***
*** 36,42
#ifdef WIN32
static unsigned int tMasterThreadId = 0;
static HANDLE termEvent = INVALID_HANDLE_VALUE;
! static int pgpipe(int handles[2]);
static int piperead(int s, char *buf, int len);
/*
--- 36,42
#ifdef WIN32
static unsigned int tMasterThreadId = 0;
static HANDLE termEvent = INVALID_HANDLE_VALUE;
! static int pgpipe(SOCKET handles[2]);
static int piperead(int s, char *buf, int len);
/*
*** readMessageFromPipe(int fd)
*** 1323,1329
* with recv/send.
*/
static int
! pgpipe(int handles[2])
{
SOCKET s;
struct sockaddr_in serv_addr;
--- 1323,1329
* with recv/send.
*/
static int
! pgpipe(SOCKET handles[2])
{
SOCKET s;
struct sockaddr_in serv_addr;
--
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] Re: popen and pclose redefinitions causing many warning in Windows build
On Wed, May 28, 2014 at 7:38 AM, Bruce Momjian br...@momjian.us wrote: On Mon, May 26, 2014 at 09:50:42PM +0900, Michael Paquier wrote: x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/interfaces/libpq -I../../../src/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include -I../pgsql/src/include/port/win32 -DEXEC_BACKEND -I/c/prog/3p64/include/libxml2 -I/c/prog/3p64/include -I/c/prog/3p64/openssl/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include/port/win32 -c -o parallel.o /home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c: In function 'pgpipe': c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c:1332:2: warning: overflow in implicit constant conversion [-Woverflow] handles[0] = handles[1] = INVALID_SOCKET; ^ c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c:1386:3: warning: overflow in implicit constant conversion [-Woverflow] handles[1] = INVALID_SOCKET; ^ In mingw-w64, SOCKET_INVALID is defined as ~0: http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/psdk_inc/_socket_types.h Is this overflow caused because SOCKET_INVALID corresponds to a 64b value in mingw-w64? Looking at the code this exists since 9.3. I think this is caused because the variable is not defined as SOCKET. The attached patch fixes this. This should prevent the warning. Wouldn't it be better to use pgsocket rather than SOCKET? Cheers, Jeff
Re: [HACKERS] Re: popen and pclose redefinitions causing many warning in Windows build
Bruce Momjian br...@momjian.us writes: I think this is caused because the variable is not defined as SOCKET. The attached patch fixes this. This should prevent the warning. Surely that's just going to move the errors somewhere else. The call site still expects the argument to be int[]. 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] Re: popen and pclose redefinitions causing many warning in Windows build
On Wed, May 28, 2014 at 12:29:28PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I think this is caused because the variable is not defined as SOCKET.
The attached patch fixes this. This should prevent the warning.
Surely that's just going to move the errors somewhere else. The call
site still expects the argument to be int[].
Ah, yes, you are right. This is a similar problem I had with libpq
where PQsocket() had to return an int.
Attached is an updated patch which follows my previous coding of
checking for PGINVALID_SOCKET, and if not equal, assigns the value to an
integer handle. I would also like to rename variable 's' to
'listen_sock', but that is not in the patch, for clarity reasons.
Should this be held for 9.5? I think it is only warning removal. On
the other hand, portability is what we do during beta testing.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/src/bin/pg_dump/parallel.c b/src/bin/pg_dump/parallel.c
new file mode 100644
index caedbb8..4efa8fb
*** a/src/bin/pg_dump/parallel.c
--- b/src/bin/pg_dump/parallel.c
*** readMessageFromPipe(int fd)
*** 1320,1337
/*
* This is a replacement version of pipe for Win32 which allows returned
* handles to be used in select(). Note that read/write calls must be replaced
! * with recv/send.
*/
static int
pgpipe(int handles[2])
{
! SOCKET s;
struct sockaddr_in serv_addr;
int len = sizeof(serv_addr);
handles[0] = handles[1] = INVALID_SOCKET;
! if ((s = socket(AF_INET, SOCK_STREAM, 0)) == INVALID_SOCKET)
{
write_msg(modulename, pgpipe: could not create socket: error code %d\n,
WSAGetLastError());
--- 1320,1342
/*
* This is a replacement version of pipe for Win32 which allows returned
* handles to be used in select(). Note that read/write calls must be replaced
! * with recv/send. handles have to be integers so we check for errors then
! * cast to integers.
*/
static int
pgpipe(int handles[2])
{
! pgsocket s, tmp_sock;
struct sockaddr_in serv_addr;
int len = sizeof(serv_addr);
+ /* We have to use the Unix socket definition here. */
handles[0] = handles[1] = INVALID_SOCKET;
! /*
! * setup listen socket
! */
! if ((s = socket(AF_INET, SOCK_STREAM, 0)) == PGINVALID_SOCKET)
{
write_msg(modulename, pgpipe: could not create socket: error code %d\n,
WSAGetLastError());
*** pgpipe(int handles[2])
*** 1363,1375
closesocket(s);
return -1;
}
! if ((handles[1] = socket(AF_INET, SOCK_STREAM, 0)) == INVALID_SOCKET)
{
write_msg(modulename, pgpipe: could not create second socket: error code %d\n,
WSAGetLastError());
closesocket(s);
return -1;
}
if (connect(handles[1], (SOCKADDR *) serv_addr, len) == SOCKET_ERROR)
{
--- 1368,1385
closesocket(s);
return -1;
}
!
! /*
! * setup pipe handles
! */
! if ((tmp_sock = socket(AF_INET, SOCK_STREAM, 0)) == PGINVALID_SOCKET)
{
write_msg(modulename, pgpipe: could not create second socket: error code %d\n,
WSAGetLastError());
closesocket(s);
return -1;
}
+ handles[1] = (int) tmp_sock;
if (connect(handles[1], (SOCKADDR *) serv_addr, len) == SOCKET_ERROR)
{
*** pgpipe(int handles[2])
*** 1378,1384
closesocket(s);
return -1;
}
! if ((handles[0] = accept(s, (SOCKADDR *) serv_addr, len)) == INVALID_SOCKET)
{
write_msg(modulename, pgpipe: could not accept connection: error code %d\n,
WSAGetLastError());
--- 1388,1394
closesocket(s);
return -1;
}
! if ((tmp_sock = accept(s, (SOCKADDR *) serv_addr, len)) == PGINVALID_SOCKET)
{
write_msg(modulename, pgpipe: could not accept connection: error code %d\n,
WSAGetLastError());
*** pgpipe(int handles[2])
*** 1387,1392
--- 1397,1404
closesocket(s);
return -1;
}
+ handles[0] = (int) tmp_sock;
+
closesocket(s);
return 0;
}
--
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] Re: popen and pclose redefinitions causing many warning in Windows build
On Fri, May 23, 2014 at 10:43 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I../../../../src/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include -I../pgsql/src/include/port/win32 -DEXEC_BACKEND -I/c/prog/3p64/include/libxml2 -I/c/prog/3p64/include -I/c/prog/3p64/openssl/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include/port/win32 -DBUILDING_DLL -c -o mingwcompat.o /home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/backend/port/win32/mingwcompat.c c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/backend/port/win32/mingwcompat.c:60:1: warning: 'RegisterWaitForSingleObject' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] RegisterWaitForSingleObject(PHANDLE phNewWaitObject, ^ This one is also an old warning, looking at the buildfarm it is present as well in REL9_2_STABLE... In mingw-w64 RegisterWaitForSingleObject is already defined in winbase.h here: http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winbase.h What do you think about adding a #ifndef _WINBASE_ block that includes LoadKernel32 and RegisterWaitForSingleObject in mingwcompat.c? x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/interfaces/libpq -I../../../src/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include -I../pgsql/src/include/port/win32 -DEXEC_BACKEND -I/c/prog/3p64/include/libxml2 -I/c/prog/3p64/include -I/c/prog/3p64/openssl/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include/port/win32 -c -o parallel.o /home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c: In function 'pgpipe': c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c:1332:2: warning: overflow in implicit constant conversion [-Woverflow] handles[0] = handles[1] = INVALID_SOCKET; ^ c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c:1386:3: warning: overflow in implicit constant conversion [-Woverflow] handles[1] = INVALID_SOCKET; ^ In mingw-w64, SOCKET_INVALID is defined as ~0: http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/psdk_inc/_socket_types.h Is this overflow caused because SOCKET_INVALID corresponds to a 64b value in mingw-w64? Looking at the code this exists since 9.3. x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I. -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/contrib/pg_stat_statements -I../../src/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include -I../pgsql/src/include/port/win32 -DEXEC_BACKEND -I/c/prog/3p64/include/libxml2 -I/c/prog/3p64/include -I/c/prog/3p64/openssl/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include/port/win32 -c -o pg_stat_statements.o /home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/contrib/pg_stat_statements/pg_stat_statements.c 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? Regards, -- Michael -- 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] Re: popen and pclose redefinitions causing many warning in Windows build
Michael Paquier michael.paqu...@gmail.com writes: On Fri, May 23, 2014 at 10:43 PM, Alvaro Herrera alvhe...@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 -- 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] Re: popen and pclose redefinitions causing many warning in Windows build
On Tue, May 27, 2014 at 1:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
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.
What about the attached?
--
Michael
diff --git a/contrib/pg_stat_statements/pg_stat_statements.c b/contrib/pg_stat_statements/pg_stat_statements.c
index 07f09e1..ffeb219 100644
--- a/contrib/pg_stat_statements/pg_stat_statements.c
+++ b/contrib/pg_stat_statements/pg_stat_statements.c
@@ -995,7 +995,15 @@ pgss_ProcessUtility(Node *parsetree, const char *queryString,
/* parse command tag to retrieve the number of affected rows. */
if (completionTag
- sscanf(completionTag, COPY UINT64_FORMAT, rows) != 1)
+ strncmp(completionTag, COPY , 5) == 0)
+ {
+#ifdef HAVE_STRTOULL
+ rows = strtoull(completionTag + 5, NULL, 10);
+#else
+ rows = strtoul(completionTag + 5, NULL, 10);
+#endif
+ }
+ else
rows = 0;
/* calc differences of buffer counters. */
--
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] Re: popen and pclose redefinitions causing many warning in Windows build
Michael Paquier michael.paqu...@gmail.com writes: On Tue, May 27, 2014 at 1:39 AM, Tom Lane t...@sss.pgh.pa.us wrote: 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. What about the attached? Looks good to me --- pushed. 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] Re: popen and pclose redefinitions causing many warning in Windows build
Heikki Linnakangas wrote: On 05/15/2014 04:15 PM, Michael Paquier wrote: On Thu, May 15, 2014 at 6:20 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: Ok, I committed #undefs. I don't have a Mingw(-w64) environment to test with, so let's see if the buildfarm likes it. There does not seem to be a buildfarm machine using MinGW-w64... Jacana. It has gcc 4.8.1 listed as the compiler, but if you look at the config in detail, it's mingw-w64. The popen/pclose warnings are there. It hasn't performed a build after I committed the fix yet. There are no warnings about popen in Jacana currently. These are the warnings that remain: x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I../../../../src/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include -I../pgsql/src/include/port/win32 -DEXEC_BACKEND -I/c/prog/3p64/include/libxml2 -I/c/prog/3p64/include -I/c/prog/3p64/openssl/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include/port/win32 -DBUILDING_DLL -c -o mingwcompat.o /home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/backend/port/win32/mingwcompat.c c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/backend/port/win32/mingwcompat.c:60:1: warning: 'RegisterWaitForSingleObject' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] RegisterWaitForSingleObject(PHANDLE phNewWaitObject, ^ x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/interfaces/libpq -I../../../src/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include -I../pgsql/src/include/port/win32 -DEXEC_BACKEND -I/c/prog/3p64/include/libxml2 -I/c/prog/3p64/include -I/c/prog/3p64/openssl/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include/port/win32 -c -o parallel.o /home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c: In function 'pgpipe': c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c:1332:2: warning: overflow in implicit constant conversion [-Woverflow] handles[0] = handles[1] = INVALID_SOCKET; ^ c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/bin/pg_dump/parallel.c:1386:3: warning: overflow in implicit constant conversion [-Woverflow] handles[1] = INVALID_SOCKET; ^ x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I. -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/contrib/pg_stat_statements -I../../src/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include -I../pgsql/src/include/port/win32 -DEXEC_BACKEND -I/c/prog/3p64/include/libxml2 -I/c/prog/3p64/include -I/c/prog/3p64/openssl/include -I/home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/src/include/port/win32 -c -o pg_stat_statements.o /home/pgrunner/bf/root/HEAD/pgsql.5100/../pgsql/contrib/pg_stat_statements/pg_stat_statements.c 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] -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: popen and pclose redefinitions causing many warning in Windows build
On 05/14/2014 06:06 PM, Noah Misch wrote: On Wed, May 14, 2014 at 05:51:24PM +0300, Heikki Linnakangas wrote: On 05/14/2014 05:37 PM, Noah Misch wrote: On Wed, May 14, 2014 at 03:15:38PM +0300, Heikki Linnakangas wrote: On 05/09/2014 02:56 AM, Noah Misch wrote: MinGW: http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/include/stdio.h#l467 MinGW-w64: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-headers/crt/stdio.h#l496 Building with any recent MinGW-w64, 32-bit or 64-bit, gets the reported warnings; building with MinGW proper does not. Hmm. The MinGW-w64 header does this: #if !defined(NO_OLDNAMES) !defined(popen) #define popen _popen #define pclose _pclose #endif So if we defined popen() before including stdio.h, that would get rid of the warning. But we don't usually do things in that order. True. I have no strong preference between that and use of #undef. I think I would prefer #undef. The risk with that is if some platform has #defined popen() to something else entirely, for some good reason, we would be bypassing that hypothetical wrapper. But I guess we'll cross that bridge if we get there. Works for me. Since (popen)(x, y) shall behave the same as popen(x, y), such a hypothetical system header would be buggy, anyway. Ok, I committed #undefs. I don't have a Mingw(-w64) environment to test with, so let's see if the buildfarm likes it. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: popen and pclose redefinitions causing many warning in Windows build
On 05/15/2014 04:15 PM, Michael Paquier wrote: On Thu, May 15, 2014 at 6:20 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: Ok, I committed #undefs. I don't have a Mingw(-w64) environment to test with, so let's see if the buildfarm likes it. There does not seem to be a buildfarm machine using MinGW-w64... Jacana. It has gcc 4.8.1 listed as the compiler, but if you look at the config in detail, it's mingw-w64. The popen/pclose warnings are there. It hasn't performed a build after I committed the fix yet. Btw, I tested latest master on a Windows box and MinGW-w64 is happier now. Thanks! - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: popen and pclose redefinitions causing many warning in Windows build
On 05/09/2014 02:56 AM, Noah Misch wrote: On Thu, May 08, 2014 at 12:14:44PM -0400, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: I'm pretty sure we need this on Mingw - this SYSTEMQUOTE stuff dates back well before 8.3, IIRC, which is when we first got full MSVC support. I tried googling for some info on this, and got a number of hits suggesting that mingw didn't emulate popen at all till pretty recently. For instance this: https://lists.fedoraproject.org/pipermail/fedora-mingw/2009-September/002087.html Jones is an ex-coworker of mine, and I'm pretty sure that if he said it wasn't there then it wasn't there. I doubt MinGW has overridden popen() at runtime; that would be contrary to its design criteria. The headers, however, are MinGW territory. MinGW declares both _popen() and popen() as functions. MinGW-w64, a project more distinct from MinGW than it sounds, uses #define popen _popen: MinGW: http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/include/stdio.h#l467 MinGW-w64: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-headers/crt/stdio.h#l496 Building with any recent MinGW-w64, 32-bit or 64-bit, gets the reported warnings; building with MinGW proper does not. Hmm. The MinGW-w64 header does this: #if !defined(NO_OLDNAMES) !defined(popen) #define popen _popen #define pclose _pclose #endif So if we defined popen() before including stdio.h, that would get rid of the warning. But we don't usually do things in that order. Could we define NO_OLDNAMES? I couldn't find any documentation on it, but it seems to a bunch of lot of wrapper functions and defines. If we can get away without them, that seems like a good thing... - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: popen and pclose redefinitions causing many warning in Windows build
On 05/14/2014 08:15 AM, Heikki Linnakangas wrote: On 05/09/2014 02:56 AM, Noah Misch wrote: On Thu, May 08, 2014 at 12:14:44PM -0400, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: I'm pretty sure we need this on Mingw - this SYSTEMQUOTE stuff dates back well before 8.3, IIRC, which is when we first got full MSVC support. I tried googling for some info on this, and got a number of hits suggesting that mingw didn't emulate popen at all till pretty recently. For instance this: https://lists.fedoraproject.org/pipermail/fedora-mingw/2009-September/002087.html Jones is an ex-coworker of mine, and I'm pretty sure that if he said it wasn't there then it wasn't there. I doubt MinGW has overridden popen() at runtime; that would be contrary to its design criteria. The headers, however, are MinGW territory. MinGW declares both _popen() and popen() as functions. MinGW-w64, a project more distinct from MinGW than it sounds, uses #define popen _popen: MinGW: http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/include/stdio.h#l467 MinGW-w64: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-headers/crt/stdio.h#l496 Building with any recent MinGW-w64, 32-bit or 64-bit, gets the reported warnings; building with MinGW proper does not. Hmm. The MinGW-w64 header does this: #if !defined(NO_OLDNAMES) !defined(popen) #define popen _popen #define pclose _pclose #endif So if we defined popen() before including stdio.h, that would get rid of the warning. But we don't usually do things in that order. Could we define NO_OLDNAMES? I couldn't find any documentation on it, but it seems to a bunch of lot of wrapper functions and defines. If we can get away without them, that seems like a good thing... Why don't we simply undefine it if it's defined before we redefine it? We don't need or want their definition, as our implementation calls _popen directly. 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
[HACKERS] Re: popen and pclose redefinitions causing many warning in Windows build
On Wed, May 14, 2014 at 03:15:38PM +0300, Heikki Linnakangas wrote: On 05/09/2014 02:56 AM, Noah Misch wrote: MinGW: http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/include/stdio.h#l467 MinGW-w64: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-headers/crt/stdio.h#l496 Building with any recent MinGW-w64, 32-bit or 64-bit, gets the reported warnings; building with MinGW proper does not. Hmm. The MinGW-w64 header does this: #if !defined(NO_OLDNAMES) !defined(popen) #define popen _popen #define pclose _pclose #endif So if we defined popen() before including stdio.h, that would get rid of the warning. But we don't usually do things in that order. True. I have no strong preference between that and use of #undef. Could we define NO_OLDNAMES? I couldn't find any documentation on it, but it seems to a bunch of lot of wrapper functions and defines. If we can get away without them, that seems like a good thing... That's a bit like compiling with gcc -std=c89 on Unix. It would lead us to add #define strdup(x) _strdup(x) and similar. I wouldn't do that. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: popen and pclose redefinitions causing many warning in Windows build
On 05/14/2014 05:37 PM, Noah Misch wrote: On Wed, May 14, 2014 at 03:15:38PM +0300, Heikki Linnakangas wrote: On 05/09/2014 02:56 AM, Noah Misch wrote: MinGW: http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/include/stdio.h#l467 MinGW-w64: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-headers/crt/stdio.h#l496 Building with any recent MinGW-w64, 32-bit or 64-bit, gets the reported warnings; building with MinGW proper does not. Hmm. The MinGW-w64 header does this: #if !defined(NO_OLDNAMES) !defined(popen) #define popen _popen #define pclose _pclose #endif So if we defined popen() before including stdio.h, that would get rid of the warning. But we don't usually do things in that order. True. I have no strong preference between that and use of #undef. I think I would prefer #undef. The risk with that is if some platform has #defined popen() to something else entirely, for some good reason, we would be bypassing that hypothetical wrapper. But I guess we'll cross that bridge if we get there. Could we define NO_OLDNAMES? I couldn't find any documentation on it, but it seems to a bunch of lot of wrapper functions and defines. If we can get away without them, that seems like a good thing... That's a bit like compiling with gcc -std=c89 on Unix. It would lead us to add #define strdup(x) _strdup(x) and similar. I wouldn't do that. Ugh. I can't believe they marked strdup(x) as deprecated. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: popen and pclose redefinitions causing many warning in Windows build
On Wed, May 14, 2014 at 05:51:24PM +0300, Heikki Linnakangas wrote: On 05/14/2014 05:37 PM, Noah Misch wrote: On Wed, May 14, 2014 at 03:15:38PM +0300, Heikki Linnakangas wrote: On 05/09/2014 02:56 AM, Noah Misch wrote: MinGW: http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/include/stdio.h#l467 MinGW-w64: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-headers/crt/stdio.h#l496 Building with any recent MinGW-w64, 32-bit or 64-bit, gets the reported warnings; building with MinGW proper does not. Hmm. The MinGW-w64 header does this: #if !defined(NO_OLDNAMES) !defined(popen) #define popen _popen #define pclose _pclose #endif So if we defined popen() before including stdio.h, that would get rid of the warning. But we don't usually do things in that order. True. I have no strong preference between that and use of #undef. I think I would prefer #undef. The risk with that is if some platform has #defined popen() to something else entirely, for some good reason, we would be bypassing that hypothetical wrapper. But I guess we'll cross that bridge if we get there. Works for me. Since (popen)(x, y) shall behave the same as popen(x, y), such a hypothetical system header would be buggy, anyway. Could we define NO_OLDNAMES? I couldn't find any documentation on it, but it seems to a bunch of lot of wrapper functions and defines. If we can get away without them, that seems like a good thing... That's a bit like compiling with gcc -std=c89 on Unix. It would lead us to add #define strdup(x) _strdup(x) and similar. I wouldn't do that. Ugh. I can't believe they marked strdup(x) as deprecated. That reflected the function's absence from ISO C, not a value judgement. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: popen and pclose redefinitions causing many warning in Windows build
On Thu, May 08, 2014 at 12:14:44PM -0400, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: I'm pretty sure we need this on Mingw - this SYSTEMQUOTE stuff dates back well before 8.3, IIRC, which is when we first got full MSVC support. I tried googling for some info on this, and got a number of hits suggesting that mingw didn't emulate popen at all till pretty recently. For instance this: https://lists.fedoraproject.org/pipermail/fedora-mingw/2009-September/002087.html Jones is an ex-coworker of mine, and I'm pretty sure that if he said it wasn't there then it wasn't there. I doubt MinGW has overridden popen() at runtime; that would be contrary to its design criteria. The headers, however, are MinGW territory. MinGW declares both _popen() and popen() as functions. MinGW-w64, a project more distinct from MinGW than it sounds, uses #define popen _popen: MinGW: http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/include/stdio.h#l467 MinGW-w64: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-headers/crt/stdio.h#l496 Building with any recent MinGW-w64, 32-bit or 64-bit, gets the reported warnings; building with MinGW proper does not. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
