Agenda for Thursday 3 August

[Jim Dehnert]

And this is done now, too.

Jim

> From samuel at indetermi.net Wed Aug  2 20:44:19 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
> 
-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272