This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch to fix PR9861


TJ Laurenzo <tlaurenzo@gmail.com> writes:

> > By the way, considering the demangler is not an unimportant point as
> > any ambiguity in demangling is an ambiguity that can be happen when
> > linking C++ and Java code together.  For example, your proposed
> > mangling for
> >     java.lang.Math.acos(double)
> > appears to be
> >     _ZN4java4lang4Math4acosEdd
> > which is the mangled name which will be used for the C++ function
> >     java::lang::Math::acos(double, double)
> 
> I think your point is valid but this situation actually wouldn't
> happen because the C++ mangler would recognize that java::lang::Math
> is a Java type and would apply the Java mangling rules.    I think
> that with this change, Java has reached the point where it needs to
> diverge from the C++ ABI and it would probably be a good idea to have
> a way to distinguish the Java form from the C++ form.  My only concern
> is that introducing a new divergent form would break existing tools
> that do demangling until they could catchup.

I may have chosen a poor example.

My point really is that if we permit mangling ambiguity, then a pure
C++ function may get the same mangled name as a Java function, even
though the functions will have different signatures.  That then
becomes a problem if you want to link C++ code with Java code in the
same executable.  It's not particularly likely, but I think it's worth
taking the extra step to make it impossible.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]