Re: Double definition of errno?

["KJK::Hyperion" <noog at libero dot it>]

At 18.54 19/08/2002, you wrote:
> For thread-safety,  a syscall reentrancy layer can be provided so that it 
> is passed the reentrancy structure.  The macro __errno_r can be used to 
> set the errno for the particular reentrancy structure.  For such 
> platforms, define the flag, -DREENTRANT_SYSCALLS_PROVIDED.
So, if I provide reentrant system calls, I can be sure that no other code 
will use "extern int"? My goal, if I wasn't clear, is to have only one 
definition of errno - for SUS compliance and for my own mental sanity

> The reentrancy struct for threading can be automatically fetched so that 
> the code only needs to #include <errno.h> and refer to errno directly in C 
> code.  This option is turned on via the dynamic reentrancy struct option 
> -D__DYNAMIC_REENT__ in libc/include/sys/config.h.
[...]

Yes, I remember this. You already told me

> Regarding your plans to change errno in the reentrant syscalls, this is 
> going to break a bunch of code because there are multiple reentrant 
> routines in newlib that directly access the reentrancy struct errno.  This 
> means that your new errno won't be set in many instances.
I didn't mean this. The "true" system calls won't set errno, they will 
return it as return value. It's much simpler this way, for a number of 
reasons. The system calls actually exposed to the code will be simple 
library calls encapsulating the "true" system calls, so they will be able 
to access the reentrancy structure