Use of _XOPEN_SOURCE?
Thu Feb 25 17:44:00 GMT 2010
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
-- 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
> 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.
> -----Original Message-----
> From: Eric Blake [mailto:firstname.lastname@example.org]
> 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
>> 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
> 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
> _POSIX_C_SOURCE nor _XOPEN_SOURCE before including a standard header,
> 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,
> I see no problem with only gating things away due to explicit request
> -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.
More information about the Newlib