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?