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 <andrew(at)dunslane(dot)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