John Levon <movem...@users.sourceforge.net> added the comment: Just came across this bug.
_XOPEN_SOURCE_EXTENDED isn't the only sticking point here: neither XPG3 nor XPG4 have C99 either: _XOPEN_SOURCE (at least with a value below 600) is definitely wrong. To quote the header: "346 * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application 347 * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, 348 * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 349 * or a POSIX.1-2001 application with anything other than a c99 or later 350 * compiler. Therefore, we force an error in both cases. " Martin, you are correct that these macros choose particular semantics in some cases. However, this does not change my point. It is a fact that specifying these macros mean what I describe, and that doing so causes significant problems in compiling Python extensions. We may wish it to be different, but it's not. As Solaris has only ever moved towards the POSIX spec, __EXTENSIONS__ is the right thing to always specify here: it enables everything "modern" that you need (*including* POSIX semantics - check that signal.h on Solaris 9 for __EXTENSIONS__), without making any claims about conformity of Python extensions (which it it is not pyconfig.h's place to say!). I hope that's a clearer explanation of why Python is doing the wrong thing both theoretically and practically for Solaris. ---------- nosy: +movement _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1759169> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com