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: [PATCH] Fix _SC_xxx and _POSIX_xxx definitions


On Tue, 2007-02-06 at 19:10 -0500, Jeff Johnston wrote:
> Corinna Vinschen wrote:
> > On Feb  6 17:32, Jeff Johnston wrote:
> >> What happened to the __rtems__ checks around _SC_STREAM_MAX and 
> >> _SC_PRIORITY_SCHEDULING?  Are these or additional RTEMS checks needed?
No, they aren't.

;) AFAIS from the newlib's cvs logs they have been added by you with the
following comment:

revision 1.30
date: 2002/04/04 22:41:11;  author: jjohnstn;  state: Exp;  lines: +5 -0

2002-04-04  Jeff Johnston  <jjohnstn@redhat.com>

        * libc/include/sys/unistd.h (_SC_STREAM_MAX, _SC_PRIORITY_SCHEDULING):
        Added for non-Cygwin, non-RTEMS configurations.

Probably you had wanted to avoid conflicts with RTEMS and Cygwin, but
this argument is moot, because we use _SC_xxx from newlib, exclusively.

> >> [...]
> >>>  It's especially noteworthy
> >>> that SUSv3 does not allow to omit any one of the _SC_xxx definitions.
Exactly, this matches with RTEMS's understanding/usage of _SC__xxx.
 
> > I thought this explains it.  See the description of unistd.h in the
> > SUSv3 man pages.
> >
> 
> Neither of us speaks for RTEMS. 
But I can ..

>  What I am wondering is if the value is 
> defined already in RTEMS and possibly already has a different value. 
No, they aren't.

As long as all non-POSIX (e.g. Cygwin-specific) _SC_xxx definitions are
properly guarded, adding POSIX-compliant _SC_xxx definitions is fine
with us - As far as can tell Corinna's patch seem OK for us.

Ralf



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