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

[Richard Frith-Macdonald]

On 2 Nov 2012, at 09:51, Wolfgang Lux wrote:

> 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 problem is that this has historically been in the code for a very long time 
and we don't know how many things it applies to (strerror is commented because 
that's the one I've been bitten by recently).

I'd also prefer to have an approach where we try to stick to a well defined a 
standard and then conditionally bracket bits of code where we are using 
non-standard features, rather than the other way round.  I guess that's a 
matter of taste.