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
