Re: [PATCH] Fix _SC_xxx and _POSIX_xxx definitions

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

Corinna Vinschen wrote:
> 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.
>
>
>   
We already have that code at the bottom of the routine so as long as the
application code properly handles getting -1 errno=EINVAL back, it is OK.

--joel
> Corinna
>
>