mangling of function names

[Jim Dehnert]

Martin von Loewis wrote:
> (Mark Mitchell wrote:)
> > However, given that we aren't going to substitute it anyway, we could
> > just relax our semantic considerations and place the (untyped) name of
> > the function into the substitution candidate list, expecting that it
> > would not be substituted later (though I suspect we could invent cases
> > in which it might).

I think that if we want different implementations to match, we need to be
much more careful than this.  Putting things in the substitution list without
the intent of substituting them seems pretty dangerous...

> That's what I'd prefer - put it in the candidate list, even if you
> know it won't be used. There are actually cases where it then would
> get substituted:
> 
> struct klasse{
>   struct methode{};
>   void methode(struct methode);
> };
> 
> void klasse::methode(struct methode){}
> 
> Now, if it is considered too difficult for implementations to detect
> that substitution is needed here, or if it is unclear from the spec
> whether substitution should happen - then that would make a point for
> complicating the spec. Otherwise, I think this _ZN6klasse7methodeES0_.

We were specifically attempting to exclude such cases.  The reason is that
a likely implementation is to mark entities from the substitution dictionary
in the symbol table, so that a search for the correct number need only be
done after a match is discovered.  So we specifically exclude substitution
of names that don't refer to the same objects.  So I think your example
should mangle as _ZN6klasse7methodeE7methode .  The example does raise
another question, though.  Is the above definition equivalent to:

void klasse::methode(struct klasse::methode){}

That would mangle as _ZN6klasse7methodeENS_7methodeE.  If both are
legitimate, and both may appear, we need to choose one or the other.

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272