[Python-Dev] Python and POSIX

Marc Recht recht at netbsd.org
Tue Sep 16 06:59:01 EDT 2003

> You should take a look at Solaris, then. Depending on whether you
> define XPG macros (I forgot which ones specifically), the socket
> functions mutate from BSD (e.g. connect(3BSD)) to XPG functions
> (connect(3XPG)). This is implemented by exposing
># pragma redefine_extname connect __xpg_connect
> or some such in socket.h, if the XPG macro is defined.
I had a quick glance at the Solaris 8 headers and it seems that's 
influenced by __EXTENSIONS__, too. So it _should_ be the same as without 
the macros.

> Likewise, on HP-UX, you select one of the three (!) curses libraries
> on the system through these macros.
Oh. Didn't know about HP-UX. That's weird.

>> So, why not split pyconfig.h up into an external and internal header?
> That would be possible if one would
> a) provide a patch, and
OK. I justed wanted to verify if there's enough interest (and no general 
rejection) in such a patch and if anyone else is already working on it.

> b) could demonstrate that, on all relevant systems, lack of such macros
>    cannot possible have an effect on proper operation of extension
> modules.
That's a bit harder since I don't have access to all "relevant" systems. I 
could test on the open-source x86 platforms, though. And IIRC CompileFarm 
has Solaris, too.
And I _believe_ that - since these changes came up with Python 2.3 (with 
the exception of _POSIX_1_SOURCE and _POSIX_SOURCE) - that it will break 
not much or anything at all if at least _XOPEN_SOURCE are moved 
_XOPEN_SOURCE_EXTENDED to an internal header (or an internal part of 
pyconfig.h). (As a first step.)

But, you're right there shouldn't be a rash decision and this needs much 
I think I'll just go on and provide a patch as basis for further discussion.


More information about the Python-Dev mailing list