errno.h changes to mark Linux specific errnos

Joel Sherrill joel.sherrill@oarcorp.com
Wed Jul 8 22:23:00 GMT 2009


Corinna Vinschen wrote:
> On Jul  8 06:56, Joel Sherrill wrote:
>   
>> Corinna Vinschen wrote:
>>     
>>> Cygwin also uses these errno values.  In case of Cygwin,
>>> __LINUX_ERRNO_EXTENSIONS__ is simply defined in include/sys/config.h:
>>>
>>>   #if defined(__CYGWIN__)
>>>   #include <cygwin/config.h>
>>>   #define __LINUX_ERRNO_EXTENSIONS__ 1
>>>   #define _MB_EXTENDED_CHARSETS_ALL 1
>>>   #endif
>>>
>>>   
>>>       
>> I'm glad you popped up Corinna.  I was worried that
>> Cygwin would suffer from this problem also.
>>
>> If Cygwin has to enable them and RTEMS has them from BSD code,
>> then they aren't Linux specific are they?
>>
>> Maybe the macro is misnamed and you almost always want these
>> enabled. 
>>     
>
> The name of the macro doesn't matter much, imho.  
I agree the name isn't important except that it currently
is lying about being Linux specific. :)
> The question is if
> it's really necessary.  Personally I'd vote for removing it entirely and
> to expose the errno values to all supported systems.  There's no gain to
> hide them.  If anything, hiding them now might result in undesirable
> errno number clashes at some later point.
>
>
>   
I agree. We didn't have problems before this went in. The
only possible value would be in reducing the strings in
strerror.

When this broke GNAT's run-time compiling, Thomas Quinot
wanted to know why this had taken so long to trip. Tinkering
with errno.h can have a variety of weird side-effects.
> Corinna
>
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985




More information about the Newlib mailing list