This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: errno.h changes to mark Linux specific errnos


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]