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

[Ian Lance Taylor <ian at wasabisystems dot com>]

Mark Mitchell <mark@codesourcery.com> writes:

> > The ABI says that an ambiguity
> > between an extern "C" name and an internal built-in type name should
> > be resolved in favor of the extern "C" name.  It doesn't say what to
> > return for an extern "C" name.  That is, it doesn't say that
> > __cxa_demangle() should return "i" when passed "i".
> 
> That's a clever reading.  I'm not sure it's what was intended, but
> then again I'm not sure that this particular interface was thought
> through very well at all.  We stayed away from these kinds of corner
> cases in our ABI testsuite because it was indeed unclear what should
> be done.

To aid my understanding of the backstory here, who wrote the ABI in
the first place?

> > In fact, I'm just writing the disambiguation code now in my demangler,
> > and my natural inclination is to write it so that when
> > __cxa_demangle() is passed "i", it returns NULL with *status set to
> > -2.
> 
> I guess that's OK.  Obviously, you or Benjamin will have to update the
> V3 testsuite.  Perhaps you could submit a patch that includes both the
> fixes for the demangler, Benjmain's tweakage of V3 to use your
> demangler, and patches to the V3 testsuite so that all the tests still
> pass?

OK, I will work on this.  On mainline I will just fix the libiberty
demangler, since I'm a libiberty maintainer anyhow.  I'll wrap those
patches up with Benjamin's for 3.4 approval.  Benjamin or you can
decide what to do for mainline libstdc++-v3.

(I'll note that I do see some advantages to having two different
demanglers, since they can serve as checks on each other--though maybe
we should combine the two testsuites.  Other than that, I'm completely
agnostic as to which demangler is in libsupc++/libstdc++-v3.)

Ian