[ Date Prev][ Date Next][ Thread Prev][ Thread Next][ Date Index][ Thread Index]
Re: [cxx-abi-dev] Name mangling question
- To: Mark Mitchell <mark@xxxxxxxxxxxxxxxx>
- Subject: Re: [cxx-abi-dev] Name mangling question
- From: nasgaard@xxxxxxxxxx
- Date: Wed, 27 Nov 2002 10:55:45 -0500
Mark, What happened to the N...E around the nested name. The type should
be N6locale5_ImplE should it not? S0_ is not the substitute for that. Is
there a caveat here that drops them?
Howard W. Nasgaard
C++ Compiler Development
e-mail: nasgaard@xxxxxxxxxx
C2/KD2/8200/MKM
905-413-3683
Tie: 969-3683
Mark Mitchell
<mark@codesourcer To: Howard Nasgaard/Toronto/IBM@IBMCA, "cxx-abi-dev@xxxxxxxxxxxxxxxx"
y.com> <cxx-abi-dev@xxxxxxxxxxxxxxxx>
cc:
11/27/2002 10:43 Subject: Re: [cxx-abi-dev] Name mangling question
AM
--On Wednesday, November 27, 2002 06:53:53 AM -0500 "nasgaard@xxxxxxxxxx"
<nasgaard@xxxxxxxxxx> wrote:
> I am having a problem understanding the mangling of function parameters
> for functions in a nested class. Given the following test case:
>
> struct locale {
> struct _Impl
> {
> void foo(_Impl&);
> };
> };
>
> int main() {
> locale::_Impl i;
> i.foo(i);
> }
>
> g+ mangles this name as _ZN6locale5_Impl3fooERS0_
>
> It would seem that 6locale would have S_ as a substitution, and
> 6locale5_Impl would have S0_. Given that the parameter is a nested name
> and so should be within N/E delimiters, I don't see how g++ arives at
> that mangling.
One of the alternatives for the <type> production is <substitution>.
Therefore, you should never get to <nested-name> for the parameter.
Here is the mistake:
<type> ::= R <type>
<type> ::= <cv-qualifiers> <type>
That last line should be:
<type> ::= <substitution>
There are definitely cases where two distinct strings will demangle to
the same name. That's because the demangler doesn't try to check that
the input string uses substitutions.
--
Mark Mitchell mark@xxxxxxxxxxxxxxxx
CodeSourcery, LLC http://www.codesourcery.com>
|