This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Fix _SC_xxx and _POSIX_xxx definitions
On Feb 7 10:56, Joel Sherrill wrote:
> Ralf Corsepius wrote:
> >On Wed, 2007-02-07 at 10:48 +0100, Corinna Vinschen wrote:
> >>> /* CYGWIN-specific values .. do not touch */
> >>> #define _SC_NPROCESSORS_CONF 9
> >>> #define _SC_NPROCESSORS_ONLN 10
> >>> #define _SC_PHYS_PAGES 11
> >>> #define _SC_AVPHYS_PAGES 12
> >>> /* end of CYGWIN-specific values */
> >>>
> >>>These have been added back in 2000, and they were never guarded with
> >>>an `#ifdef __CYGWIN__'. All four values are supported by Linux, FWIW.
> >>>When I patched sys/unistd.h yesterday, I contemplated the idea to
> >>>guard them. However, since they were *never guarded, I don't know
> >>>if they aren't actually supported by RTEMS.
> >>>
> >They aren't - We only support a very limited subset of them at all ;)
> >
> >
> >> That's why I left them
> >>
> >>>unguarded. Is that ok with you?
> >>>
> >Technically yes - They don't cause any problems for RTEMS.
> >Personal preference, no, but ...
> >
> >
> >>btw., if you also use them, I would remove the above comments. They
> >>wouldn't make sense, right?
> >>
> >Are they used by anybody but cygwin?
> >
> >The only reason for me preferring seeing them guarded is
> >"generality/os-independence/cleanliness" of the code. Given the fact
> >they had been present before, it's nothing I want to insist on.
> >
> >
> I agree with Ralf. Not a big deal either way. I don't feel any pressure to
> support them but if enough code uses them, we would likely try to find
> a reasonable way to support them.
I think that's not a deal either way. Just because an _SC_xxx value
exists, doesn't mean you have to support the option. It's still
perfectly valid to return -1 and set errno to EINVAL.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat