This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]