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
