This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Proposed change to libstdc++ demangler (was: Re: g++ rejects declaration of reference to array?)
On Fri, Oct 17, 2003 at 01:48:25PM +0200, Andreas Schwab wrote:
> IMHO that's a bug in the demangler. It should be "const int (&)[3]".
c++filt is the libiberty demangler, which is full of bugs.
The demangler in libstdc++ (that my humble person tries to keep bug free)
demangles this as:
void foo<int[3]>(int ( const&) [3])
and not
void foo<int[3]>(int const (&) [3])
so, there is a bug here too.
I created the following test program:
#include <iostream>
template<typename T>
void
foo(T const&)
{
std::cout << "Calling \"template<typename T> void foo(T const&)\".\n";
}
typedef int const (& t1) [3];
template<>
void
foo(t1)
{
std::cout << "Calling \"template<> void foo(int const (&) [3])\".\n";
}
typedef int (* const& t2) [3];
template<>
void
foo(t2)
{
std::cout << "Calling \"template<> void foo(int (* const&) [3])\".\n";
}
int main()
{
int x[3];
foo(x); // Instantiation leads to _Z3fooIA3_iEvRKT_
foo(&x); // Instantiation leads to _Z3fooIPA3_iEvRKT_
return 0;
}
My conclusion is that the follow change needs to be made to the demangler
of libstdc++. The following comment describes the current qualifier
decoding behaviour:
mangled name output
// <Q>[K|V|r]+ ==> [ const| volatile| restrict]+Q
...
// <Q>A<I> ==> (Q) [I]
// Note that when <Q> ends on an A<I2> then the brackets are omitted:
// A<I2>A<I> ==> [I2][I]
Where <Q> is a qualifier and <I> an array index.
Apparently this should be changed to:
// <Q>[K|V|r]+A<I> ==> [ const| volatile| restrict]+ (Q) [I]
where the <Q> is not allowed to end on [K|V|r]+.
In less formal words, the 'const' etc. "falls through" the left brace
and
int ( const&) [3] becomes int const (&) [3]
If nobody rejects to this analysis then I'll write a patch for it
(which will probably be approved by Benjamin, because as the original author
he trusts me blindly to do-the-right-thing(tm) (right Ben? :), hence that
comments to this analysis are not-to-be-under-estimated(tm) ;)).
Comments anyone?
--
Carlo Wood <carlo@alinoe.com>