This is the mail archive of the
mailing list for the libstdc++ project.
Re: New demangler in C++
On Thu, 2003-02-27 at 09:30, Benjamin Kosnik wrote:
> >If the new version is better we should use it -- but better should
> >include the fact that it can truly replace the old version.
> I disagree on this critieria. I think we'll just have to disagree on
> this issue.
> >Is it just in V3 or in libiberty as well?
> Does libiberty have __cxa_demangle?
Why do you say that? In my copy of cp-demangle.c, I see:
#if defined(IN_LIBGCC2) || defined(IN_GLIBCPP_V3)
extern char *__cxa_demangle PARAMS ((const char *, char *, size_t *, int
> Again, this is just a replacement for __cxa_demangle, the v3 demangler
> as specified by the IA 64 C++ ABI, not the uber-demangler as used in
> libiberty that tries to do v2, v3, hp, lucid, arm, java etc.
cp-demangle.c is not an uber-demangler; it is the Itanium C++ ABI
demangler. The other demanglers are in cplus-dem.c.
I think you've now replaced exactly the functionality of cp-demangle.c,
but in a way that results in code duplication. And in situations where
a user program linking with libiberty and with libstdc++ will see
different demanglings depending on which entry point it calls.
For example, this now means that GDB will demangle names differently in
a C++ program than you will get from calling __cxa_demangle from inside
This is a bad thing.
You've also created a new demangler testsuite, but, as far as I can
tell, the old demangler tests don't get run with the new demangler, and
the new demangler tests don't get run with the old demangler.
This is also a bad thing.
This isn't something I'm prepared just to agree to disagree about.
I think it's far too important that we avoid duplicating this code.
mark at codesourcery dot com