Writing to ostreams from operator new.

[Carlo Wood <carlo at alinoe dot com>]

More in general: "Writing to ostreams from malloc".
                                           ------

This was discussed this before, and the concensus was that calling
functions of libstdc++ from malloc isn't "correct" and therefore does
not need to be supported.  However, an (allocation) debugging library
NEEDS to write (debug) output from malloc; or at least, it would help
a lot if that was possible.  Therefore I hope that you will consider
to support this.

There are two problems related to using std::cout (etc) from malloc().

1) operator new is called from ios_base::Init::Init() *before* the
   iostreams are initialized: writing to cout in that case leads to a
   crash.

   (history: http://gcc.gnu.org/ml/libstdc++/2001-05/msg00189.html
    with a correction in
    http://gcc.gnu.org/ml/libstdc++/2001-05/msg00190.html,
    and http://gcc.gnu.org/ml/libstdc++/2001-07/msg00061.html)

2) General ostreams like std::cout use the STL std::alloc as internal
   buffer which shares it's memory pool with everything else through
   static pointers and therefore needs locking.  Because of this locking
   it can not be called recursively and when memory needs to be allocated
   through malloc as a result of writing to std::cout (for example)
   from malloc called from any other std::alloc, a dead lock occurs.

Point 1) is simple to solve.

[ and I still think that the current situation isn't conforming to the
  standard as paragraph 27.4.6.1 says

  1 The class Init describes an object whose construction ensures the
    construction of the eight objects declared in <iostream> (27.3)
    that associate file stream buffers with the standard C streams
    provided for by the functions declared in <cstdio> (27.8.2).

  it doesn't say that this doesn't have to work from an overloaded
  operator new. ]

Point 2) means the need to change __default_allocator<true, 0> in a
way such that the lock is not set during the call to malloc.  Also this
is not a problem: one only really needs to lock (protect) the static
pointers.  There is no reason to hold the lock during the call to
malloc.

I am not trying to argue that this must be supported based on the
standard, but I see no reason not to make these changes.  It would
greatly help memory allocation debugging libraries for C++ to allow
I/O from malloc.

Would there be any objection against these changes?  I am willing to
write the patch, obviously.

-- 
Carlo Wood <carlo@alinoe.com>

PS (Could this be scheduled for 3.0.3, or does it have to be against 3.1?).