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
