gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On linux too (was Re: Base compilation broken on NetBSD)


From: Wolfgang Lux
Subject: Re: On linux too (was Re: Base compilation broken on NetBSD)
Date: Fri, 2 Nov 2012 10:51:38 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]