Re: Double definition of errno?

["J. Johnston" <jjohnstn at redhat dot com>]

KJK::Hyperion wrote:
> 
> 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
> 

Yes.

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

I misunderstood.  Yes, you want any "true" system call to return the errno value and
then you wrap it so as to place the value into newlib's errno.

-- Jeff J.