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

[Ian Lance Taylor]

Benjamin Kosnik <bkoz@redhat.com> writes:

> An experimental patch to use the libiberty cp-demangle routines in
> libsupc++/__cxa_demangle is attached. An additional (small) patch is
> needed for libiberty/cp-demangle.c.

Thanks for testing this.

> I have 4 new fails when it's used. 
> 
> FAIL: demangle/abi_examples/01.cc execution test
> FAIL: demangle/abi_examples/02.cc execution test
> string: f
> libiberty: float
> libstdc++: f
> 
> I think libiberty is pretty clearly wrong here, just based on the C++ ABI docs.

Frankly, the C++ ABI docs don't make any sense.

This is what I see in
    http://www.codesourcery.com/cxx-abi/abi.html#demangler

    Ambiguities are possible between extern "C" object names and
    internal built-in type names, e.g. "i" may be either an object
    named "i" or the built-in "int" type. Such ambiguities should be
    resolved to user names over built-in names.

In fact, there are many mangled type name which are possible extern
"C" object names--the only expections are mangled names which start
with class names which start with a length in digits.  If
__cxa_demangle() is supposed to demangle "f" as "f" rather than
"float", then why shouldn't it demangle "ri" as "ri" rather than "int
restrict"?  Or "FiiE" as "FiiE" rather than "int ()(int)"?  Why single
out built-in type names?

Since __cxa_demangle is documented in this strange manner, I will
implement it.  But I don't plan to change c++filt.

Ian