Agenda for Thursday 3 August

Alex Samuel samuel at codesourcery.com
Thu Aug 3 03:43:37 UTC 2000


Jim Dehnert <dehnert at baalbek.engr.sgi.com> writes:

  Jim>   2) Mangling grammar modifications.  There's an outstanding
  Jim> ambiguity question, and the previously suggested solution would
  Jim> eliminate substitution for some names, we thought.  Can you
  Jim> look at this again, Alex?

I'm a bit confused here.  The current ABI draft has this production (in
red):

    <name> ::= <substitution>  # (problem for name w/o signature)

I don't think this is an open issue anymore; I'm pretty sure we
decided conclusively that, for good reasons, the name of a function
without its parameter types should not be a substitution candidate.

I think the production that's still at issue is

    <encoding> ::= <substitution>

This production was present in my original grammar reformulation, but
I asked that it be removed because of the abiguity with the sequence

    <encoding> ::= <name>
    <name> ::= <unscoped-template-name>
    <unscoped-template-name> ::= <substitution>

I feel that reintroducing the substitution of <encoding>s would
significantly complicate the implementation of demanglers (including
the existing implementation that we've debugged), and make it much
harder to get right.  In fact, I'm not even sure it's possible.  

The only place you're hurt by not having this substitution, I think,
is if you reference the same external name more than once in template
arguments, for instance

    typedef void (*fnptr_t)();
    template<fnptr_t T, fnptr_t U> class Bar {};

    extern void foo();
    template Bar<foo, foo>; 

In this case, foo is mangled twice.  This shouldn't even hurt too
much, because in non-trivial cases significant subcomponents of the
second <encoding> should be substituted away.

So, given that it would complicate both existing demangler
implementations and demangler implementations in principal, without
saving much, I strongly suggest not including this production.

Regards
Alex




More information about the cxx-abi-dev mailing list