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