analysis of libiberty/cp-demangle.c for libsupc++/__cxa_demangle

[Benjamin Kosnik]

The patch I posted earlier was merely a feasibility study. 

>If it is decided to keep the demangler, then I surely hope it won't be
>removed "tomorrow" (or in 3.5, or 3.6): I don't like code duplication,
>and once it is a part of libstdc++ I will start to use it from there and
>remove it from libcwd (as such providing a garantee for maintenance and
>testing too).  You understand that I am reluctant to do this unless it
>becomes a more or less permanent extension to libstdc++.

I think Ian, Gaby, Phil, and I at least would like to see your demangler
remain in the libstdc++ sources. As Ian has indicated, there are
advantages, not disadvantages, to having two different but correct
demangler implementations. Also, the C++ demangler does have unique
features that are not part of the libiberty demangler.

The immediate, must-solve problem we are having is with having
__cxa_demangle as a self-contained part of libsupc++.  I don't see a way
to have this functionality and use the C++ demangler.

I propose the following:

1) your patch of yesterday + my patches to add an type parameter get
applied to demangle.h.

2) this gets moved to include/ext/demangle.h

3) We move __cxa_demangle into libsupc++ and use libiberty's code for this function.

Thoughts? Is this acceptable to everybody? 

-benjamin