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] |
I have put it into sys/features.h and included sys/features.h at the beginning of sys/config.h, as you suggest. The patch is attached. I built it under Cygwin and Linux and nothing failed. I noticed one thing that makes me wonder slightly as to whether it would need addressing is that in sys/unistd.h, line 260 includes sys/features.h, but this is after a check for _POSIX_SOURCE, the old (1990) form of _POSIX_C_SOURCE (line 196). It's only gating one function prototype (vfork()). IF we were to later try to attempt to do something with _POSIX_SOURCE, the prior inclusion of sys/features.h (due to being pulled in at the top) MIGHT make a difference. I'm thinking that this is not worth worrying about. Speaking of _POSIX_SOURCE, it appears in 19 files under libc, all of which are just checks for it. Something to do later. (A note for the mailing list archive as a reminder for when we might: 2001 says "Since _POSIX_SOURCE specified by the POSIX.1-1990 standard did not have a value associated with it, the _POSIX_C_SOURCE macro replaces it, allowing an application to inform the system of the revision of the standard to which it conforms. This symbol will allow implementations to support various revisions of IEEE Std 1003.1-2001 simultaneously. For instance, when either _POSIX_SOURCE is defined or _POSIX_C_SOURCE is defined as 1, the system should make visible the same name space as permitted and required by the POSIX.1-1990 standard. When _POSIX_C_SOURCE is defined, the state of _POSIX_SOURCE is completely irrelevant.") A secondary question: given that this change now makes anything that includes any system header end up with sys/features.h, should a cleanup be done to take out all #include <sys/features.h> to avoid confusion? Or would it be worse for them to not have it and be assumed? (It's obviously easier to do nothing.) Craig -----Original Message----- From: Jeff Johnston [mailto:jjohnstn@redhat.com] Sent: Thursday, February 25, 2010 12:44 PM To: Howland Craig D (Craig) Cc: Newlib Subject: Re: Use of _XOPEN_SOURCE? 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.
Attachment:
xopen_patch.txt
Description: xopen_patch.txt
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |