[PATCH] Fix _SC_xxx and _POSIX_xxx definitions

Joel Sherrill joel.sherrill@oarcorp.com
Wed Feb 7 17:00:00 GMT 2007


Ralf Corsepius wrote:
> On Wed, 2007-02-07 at 10:48 +0100, Corinna Vinschen wrote:
>   
>> On Feb  7 10:35, Corinna Vinschen wrote:
>>     
>>> On Feb  7 07:36, Ralf Corsepius wrote:
>>>       
>>>> 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.
>>>>         
>>> Uh, there's one problem here.  There are four definitions which are
>>> non-POSIX:
>>>       
> ... then, I must have missed them ;)
>
>   
>>>   /* 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.

--joel
> Ralf
>
>
>   



More information about the Newlib mailing list