Marc Recht <recht at netbsd.org> writes: > 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. While that is true, I would hope that you come to the conclusion that these macros can potentially do much more than simply hiding library functions. Instead, their *primary* purpose is to request Single Unix behaviour in case a platform implements both the standard behaviour, and the traditional one (regardless of which tradition the system follows). So I would be *very* careful to enable these macros only for a few translation units; I'm pretty sure that the "law" would be on the vendor's side if inconsistent usage of these defines would be found to cause problems, in Irix 27, or ValueBSD 3. > 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. If the change is only for 2.4, that would be fine - that code hopefully will get testing on several other platforms before 2.4 is released. > 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). Believes should not be trusted too much when it comes to portability. If you can think of an obscure interpretation of some standard, it is almost certain that there is some vendor out there who has chosen that interpretation. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4