Problems with __cxa_demangle and the verbose terminate handler

[Carlo Wood]

On Sun, Feb 22, 2004 at 10:39:05PM -0800, Zack Weinberg wrote:
> 
> I don't know what the French means, but I think the burden should be
> on the C++ demangler proponents to explain why it should be kept.  The
> C demangler used to be buggy, but now it has been fixed, so it is
> strictly more useful now; why do we need two implementations?

When I was asked to donate the code of my demangler, which was the
only one at the time - and to turn the license into a LGPL one
or something like that - I agreed, but wanted to be sure that I
could use it from libstdc++ too then; and therefore asked for
the promise to add it with the templated interface.

And exactly that is the pre- of this implementation: it allows
the writers of debug applications, like myself, to control the
allocator that is being used.  This gives control over where
and how memory is being allocated.

It allows one to pre-allocate memory, use a different memory pool
seperated from other STL memory pools, or set a special flag
before calling malloc() - all of which I do and need.

However, people were like "we don't need that for __cxa_demangle"
and stuff - and they wanted a simple demangle interface.  So,
__cxa_demangle just uses the normal std::allocator.

We can change that however.

The restriction that it may not throw exceptions was never brought
under my attention.  I feel slightly annoyed by that fact, because
I put a lot of extra time into the demangler as a result of your
request to use it - and when as a result of this it would be
removed again from the source even before the first release of 3.4
then you*) wasted a large amount of my time.

-- 
Carlo Wood <carlo@alinoe.com>

PS There is one place where 'new' is called directly - this
   should probably be changed to use the past Allocator as
   well.  That is not a problem to do and from that moment
   on we know that all memory allocation and deallocation
   will be done through the Allocator that is being passed.

*) you = the gcc maintainers in general.  I am not going
   to point fingers, nor do I have anyone special in mind.