Re: Queries concerning RTOS protection in newllib

[Corinna Vinschen <vinschen at redhat dot com>]

On Jun 17 14:32, Antony KING wrote:
> Hi Corinna,
> 
> Which part of the patch was causing the problem ? Was it just the 
> introduction of _global_impure_ptr ? I recently discovered a problem 

As far as I can see, yes.  Since impure_ptr is manipulated a lot in Cygwin,
changing _GLOBAL_REENT from _impure_ptr to _global_impure_ptr is a big
problem.  If I keep all other patches but revert _GLOBAL_REENT to be defined
as _impure_ptr, everything seems to work fine. 

> which was exposed by this patch when the _cleanup_r function was changed 
> from walking the FILE object list with fflush() to fclose(). I wonder if 
> this is the cause of the unexpected truncation.

I didn't see any negative result of this change so far.

> in addition to the above change (in _cleanup_r) perhaps the definition 
> of _GLOBAL_REENT can also be conditional on whether newlib is being 
> targeted for Cygwin, e.g. (in libc/include/sys/reent.h):
> 
> #ifdef __CYGWIN__
> #define _GLOBAL_REENT _impure_ptr
> #else
> #define _GLOBAL_REENT _global_impure_ptr
> #endif
> 
> which may restore the behaviour you need. Alternatively as well as 
> manipulating _impure_ptr Cygwin can manipulate _global_impure_ptr as well.

As I said, reverting _GLOBAL_REENT to _impure_ptr restores the correct
behaviour again.  I still don't quite understand the invention of
_global_impure_ptr.  _GLOBAL_REENT is used a lot in newlib and due to
it's redefinition to another global variable, all this functionality
is potentially accessing the wrong datastructure.  If you actually
need a never changing _global_impure_ptr, then that's ok, but it shouldn't
be used by default from all these functions and therefore not be defined
as _GLOBAL_REENT, should it?


Corinna

-- 
Corinna Vinschen
Cygwin Co-Project Leader
Red Hat, Inc.