[cxx-abi-dev] Pointer to member function mangling

[Jason Merrill]

>>>>> "Mark" == Mark Mitchell <mark at codesourcery.com> writes:

>>> g++ currently emits
>>> 
>>> MK1AFvvE
>>> 
>>> or, member of class "const A" of type "function of (void) returning
>>> void". I don't see how this can be deduced from the above text.  More
>>> consistent with the handling of function names, and suggested by the
>>> text in the function type section, would be
>>> 
>>> MNK1AEFvvE
>> 
>> I don't see that: there is no <nested-name> in the pointer-to-member
>> above.

> I don't think this is very clearly specified.

> Reading literally, a pointer-to-member type is:

>   M <class type> <member type>

> The problem is that the member type is a function type, and for
> function types we don't ever emit the this parameter, so were
> does the const-ness go?

> Your suggestion here implies a nested name, which Daveed rightly
> points out is not present.

Well, the first paragraph I quoted says that the nested name form should be
used in this case even when there's no nesting.  I don't see how that could
apply to member function names, which are always qualified by their class
type; from this I conclude that it's meant to refer to the pmf case.  Not
that I think this is a good idea, mind you.

>>> IMO more consistent with the language semantics would be
>>> 
>>> M1AKFvvE

> This suggestion is fine, but not supported by the grammar.  This
> would imply a member whose function type is const -- i.e., something
> equivalent to "g" in:

>   typedef void (f)();
>   typedef const f g;

> That's not the right type.

No, in fact that code snippet is ill-formed.  Since you can't create a
cv-qualified function type as above, there's no ambiguity.  Again, the
cv-quals are considered part of the function type:

  8.3.5  Functions                                             [dcl.fct]

1 In a declaration T D where D has the form
     D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
     exception-specificationopt
  and the type of the contained declarator-id in the declaration T D1 is
  derived-declarator-type-list T," the type of the declarator-id in D is
  "derived-declarator-type-list  function   of   (parameter-declaration-
  clause)  cv-qualifier-seqopt  returning  T";  a type of this form is a
  function type86).

> The G++ implementation is relatively logical.  Instead of encoding

>   void ()(const A*)

> as everyone used to, we now do:

>   const A ... void ()

Fair enough.  But it's a real pain to demangle, as I've discovered
recently.  You have to remember the 'const A' for later substitution, and
then break it up into pieces to go at various points in the output.  The
current demangler does a pretty bad job of handling function declarators in
general.

> So, while I would be the last to argue that the spec is 100% clear,
> I think it supports the G++ version as well as any of the other
> ones.

>>> What do other compilers produce?  What do other demanglers expect?

> This is the right question.  At this point, none of HP, Intel, GNU,
> or anyone else is going to be eager to change their compilers.

Certainly; I mainly wanted to find out if there was any disagreement in
existing practice before the gcc 3.1 release.

Jason