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] |
On Nov 26 14:04, Joel Sherrill wrote: > On 11/25/2013 4:07 AM, Corinna Vinschen wrote: > > On Nov 23 16:42, Joel Sherrill wrote: > >> On 11/23/2013 3:39 PM, Corinna Vinschen wrote: > >>> We don't actually utilize _GNU_SOURCE or __USE_GNU in newlib so > >>> far, except in libc/sys/linux. We just don't have the detailed > >>> features.h in place as glibc has. What we really have is > >>> _POSIX_SOURCE and __STRICT_ANSI__, and a teensy little bit of > >>> __XSI_VISIBLE, __POSIX_VISIBLE and __BSD_VISIBLE. The last three > >>> are only rarely used, and we shouldn't start using them or others > >>> more often, unless we have the matching feature test macros defined > >>> in features.h along the lines (but not necessarily identical to) > >>> glibc. IMHO. > >> > >> Unfortunately, these really are the glibc APIs and provided to > >> increase compatibility between RTEMS and GNU/Linux. > >> > >> I would like to see us move more to the feature macros and away > >> from the list of OSes we have now. I know it is a lot of details > >> though. > > > > I'm all for defining a formal feature macro system in features.h, but... > > > >> In this case, this is a GNU extension and is intentionally so. > >> If we just mark it with __rtems__, we are not following glibc. > > > > ...we didn't set this detailed system up yet. What I'm trying to > > say is just this. Shouldn't we fist make sure to set up our formal > > feature test macro system in features.h and only then introduce the > > newly defined macros? > > OK. features.h has pretty thorough POSIX features for RTEMS, > XMK, and Cygwin. There is an svr4 define which I don't know > what trips. > But the bottom section has this comment: > > /* Per the permission given in POSIX.1-2008 section 2.2.1, define > * _POSIX_C_SOURCE if _XOPEN_SOURCE is defined and _POSIX_C_SOURCE is not. > * (_XOPEN_SOURCE indicates that XSI extensions are desired by an > application.) > * This permission is first granted in 2008, but use it for older ones, > also. > * Allow for _XOPEN_SOURCE to be empty (from the earliest form of it, > before it > * was required to have specific values). > */ > > I take that to mean _POSIX_C_SOURCE and _XOPEN_SOURCE > can be used or derived from. > > features.h doesn't look in too bad of a shape. cdefs.h is > from FreeBSD and interprets those and gives us > ___XSI_VISIBLE, __POSIX_VISIBLE, __ISO_C_VISIBLE, > and __BSD_VISIBLE. This is pretty new. I hadn't taken in that we have this stuff for a few months now and I expected it in features.h, as in glibc, rather than in sys/cdefs.h as on BSD. Oh well. > We are just asking to add a trip for __GNU_VISIBLE and use > it. Well, sure. __GNU_VISIBLE is an internal macro, though. We should add a _GNU_SOURCE enabling expression in sys/cdefs.h as well. AFAICS it should be something like everything else plus __GNU_VISIBLE: #if defined(_GNU_SOURCE) #define __POSIX_VISIBLE 200809 #define __XSI_VISIBLE 700 #define __BSD_VISIBLE 1 #define __ISO_C_VISIBLE 2011 #define __GNU_VISIBLE 1 I'm just not sure where exactly to add it. In theory it should override all other choices except _POSIX_C_SOURCE, maybe. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
pgp9BSouqB2Ws.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |