[uClibc]Re: errno confusion

[David McCullough]

Jivin Miles Bader lays it down ...
> Any response to this?
> 
> My gut feeling is that:
> 
>  (1) For systems without threads (__UCLIBC_HAS_THREADS__ undefined),
>      `errno' should never be defined, and should just be normal
>      variable.
> 
>  (2) For systems _with_ threads (__UCLIBC_HAS_THREADS__ defined),
>      `errno' should be defined the same regardless of whether _LIBC is
>      defined or not; code that needs to do something special inside uclibc
>      can explicitly undefine it.
> 
>      [as I mentioned before, at least <linux/asm/unistd.h> tries to
>      write to errno, and so system call sturbs might currently do the
>      wrong thing in a threaded uclibc]
> 
> Thus the previously mentioned code inside common/bits/errno.h would
> become:
> 
>    #  if defined __UCLIBC_HAS_THREADS__ || defined _LIBC_REENTRANT
>    /* When using threads, errno is a per-thread value.  */
>    #   define errno (*__errno_location ())
>    #  endif
> 
>    #  if defined _LIBC
>    /* We wouldn't need a special macro anymore but it is history.  */
>    #   define __set_errno(val) (errno) = (val)
>    #  endif /* _LIBC */
> 
> [I'm not sure what the implication of _LIBC_REENTRANT is though, so
> perhaps that test is wrong]
> 
> Does anyone see problems with this?

Everything you have said makes sense to me.

I'd say if there are no objections do it.

The only trick is that the assembler on platforms that do both
threads/non-threads may need changing.  Given that no one likes to change
working asm,  it may be better if each platform can choose how it operates.

So for the 850 you might have a define in features.h or elsewhere in "bits"
that says errno is just referenced directly rather than via a function.

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security