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] |
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. -- Don't work too hard, make some time for fun as well! Eric Blake ebb9@byu.net
Attachment:
config_h.patch
Description: config_h.patch
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |