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