Use of _XOPEN_SOURCE?

[Jeff Johnston]

I'm thinking this might be better situated in sys/features.h at the 
bottom and then have sys/config.h include sys/features.h or 
alternatively still have sys/config.h include sys/features.h before this 
check.  This would be along the lines of glibc where features.h is used 
everywhere.

-- Jeff J.

On 25/02/10 12:29 PM, Howland Craig D (Craig) wrote:
> For the sake of beginning to do something, the attached patch adds
> defining _POSIX_C_SOURCE in config.h if _XOPEN_SOURCE has been defined
> but _POSIX_C_SOURCE has not been, per POSIX.1-2008.  This is merely
> the beginning of an aid for the larger topic.
>
> I put this into this email thread since it is pretty directly related,
> but see also http://sourceware.org/ml/newlib/2010/msg00178.html for
> how it relates to other work in progress (the discussion about
> strftime).
>
> I chose config.h because it is included by everything.  It is not
> necessarily an ideal fit versus the name, but it does seem to fit
> into config.h better than in _ansi.h.
>
> See the patch for the details.  I did not yet attempt to do anything
> about the older _POSIX_SOURCE (from 1990), thinking that since looking
> at this has come so late that perhaps we can forget about that and
> just look to _POSIX_C_SOURCE.
>
> Craig
>
>
> -----Original Message-----
> From: Eric Blake [mailto:ebb9@byu.net]
> Sent: Tuesday, February 23, 2010 9:00 PM
> To: Howland Craig D (Craig)
> Cc: Newlib
> Subject: Re: Use of _XOPEN_SOURCE?
>
> According to Howland Craig D (Craig) on 2/23/2010 6:07 PM:
>> Two questions arise.  (I'm working on a cleanup of math.h, and to
>> be the cleanest this would need to be done, which is why it has come
>> up.)
>>
>> 1)  Should we even consider adding _XOPEN_SOURCE gates?  (Doing so
>> could cause things to break for people, unless we were to also define
>> _XOPEN_SOURCE by default in some place like config.h or newlib.h.
>> But then that would defeat the intention of the POSIX requirement
>> that the user define _XOPEN_SOURCE to get the extensions.)
>
> Yes.  Ultimately, it would be nice to honor the current standard, and
> possibly even several versions of standards, according to appropriate
> gates.  But given how much time has been spent on that on glibc (even
> now,
> 15 months after POSIX 2008, there are still bug reports being actively
> filed about incorrect symbols in glibc), it won't be trivial.
>
> And yes, it is appropriate to have non-standard symbols exposed by
> default.  The way POSIX is worded, if the user does NOT pre-define
> either
> _POSIX_C_SOURCE nor _XOPEN_SOURCE before including a standard header,
> then
> all bets are off.  Whether we emulate glibc and also provide _GNU_SOURCE
> as a gate that exposes everything under the sun is a different matter,
> but
> I see no problem with only gating things away due to explicit request
> (gcc
> -std=c99, -D_XOPEN_SOURCE=700, etc), and leaving them exposed otherwise.
>
>> 2)  What value would we want to look for?  (Is my example above the
>> right way?  Or would we attempt to tie ourselves to a single version
>> like POSIX.1-2008 and use fixed 700?  etc.)
>
> It depends on how many versions of how many standards we want to support
> at once.  Personally, I only care about the latest standard, so checking
> for just 700 is an acceptable patch for me.  But going all the way, and
> introducing multiple gates according to version is also a nice goal.
>