Richard Frith-Macdonald wrote: > On 2 Nov 2012, at 09:19, Wolfgang Lux wrote: > >> David Chisnall wrote: >> >>> On 2 Nov 2012, at 09:05, Wolfgang Lux wrote: >>> >>>> Do we need to define _XOPEN_SOURCE at all? In the headers on OS X I found >>>> this comment: >>>> Defining _POSIX_C_SOURCE or _XOPEN_SOURCE restricts the >>>> available APIs to exactly the set of APIs defined by the >>>> corresponding standard, based on the value defined. >>>> I guess (at least) other BSD based systems handle this macro similarly >>>> (I'm too lazy to fire up a VM to check). >>> >>> Yes, BSD libc uses the macro in this way. Unfortunately, glibc uses it in >>> the opposite way, and *only* exposes standard functionality if these macros >>> are defined. *BSD libc defaults to exposing everything, glibc defaults to >>> exposing a very limited subset. This gets doubly irritating on glibc >>> because there are some pairs of functions that it is not possible to >>> simultaneously expose, because some are POSIX and some are from BSD and the >>> feature macros to expose one hide the other... >> >> I'm not sure what libc Ubuntu aka Debian uses, but I gave it a quick try and >> added this to common.h (below the definition of _XOPEN_SOURCE) >> #ifdef _XOPEN_SOURCE >> # undef _XOPEN_SOURCE >> #endif >> and, guess what, gnustep-base still compiles fine. So my question still >> stands: Do we really need to define _XOPEN_SOURCE? > > Yes you NEED _XOPEN_SOURCE ... because it selects which, of different variant > of some functions, you actually get to use. > So without it the code may compile but not run correctly. > > The example that springs to mind is strerror_r() ... if you don't have it > defined then any system error messages in NSError or in logs will contain > garbage.
Sorry for being dumb (and for not reading the comment in common.h, which said exactly that). But if this only affects the strerror_r function, wouldn't it be simpler to have two versions of the code in the _systemError: method (one for the GNU version and one for the POSIX version) instead of this nasty fiddling with preprocessor macros that seems hard to get right for everyone? My strerror_r man page (on Ubuntu) tells me The XSI-compliant version of strerror_r() is provided if: (_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE Otherwise, the GNU-specific version is provided. So we could use something like # if (_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE <<our current code>> # else <<variant of the code with strerror_r returning a buffer>> # endif And if relying on this man page information looks to shaky, maybe we would come up with an autoconf test to check which variant is chosen? Wolfgang _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev