[PATCH] Fix _SC_xxx and _POSIX_xxx definitions

[Joel Sherrill]

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
>
>