Re: popen and pclose redefinitions causing many warning in Windows build
От | Andrew Dunstan |
---|---|
Тема | Re: popen and pclose redefinitions causing many warning in Windows build |
Дата | |
Msg-id | 53737C23.5000101@dunslane.net обсуждение исходный текст |
Ответ на | Re: popen and pclose redefinitions causing many warning in Windows build (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-hackers |
On 05/14/2014 08:15 AM, Heikki Linnakangas wrote: > 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@dunslane.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... > > Why don't we simply undefine it if it's defined before we redefine it? We don't need or want their definition, as our implementation calls _popen directly. cheers andrew
В списке pgsql-hackers по дате отправления: