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.