Re: New demangler in C++

[Mark Mitchell <mark at codesourcery dot com>]

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? 
> 
> (No.) 

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
the program.

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 Mitchell
CodeSourcery, LLC
mark at codesourcery dot com