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


> If we could find an encoding format that was recognized by the current
> demangler and provided uniqueness guarantees consistent with the new
> patch, this could work.... perhaps a flag character somewhere that the
> current demangler would ignore instead of abort on.

For example, if instead of encoding the return type prior to all of
the other types, we could encode it after an implied "void" at the end
of the signature.  This would be unambiguos and recognizable for
patched toolsets but would provide some degree of backwards
compatibility.  For example, the encoding for Math.pow would be:
_ZN4java4lang4Math3powEddvd
Under an unpatched toolset, this would demangle to:
   java.lang.Math.pow(double, double, void, double)
A patched toolset could recognize the pattern and instead print:
   double java.lang.Math.pow(double, double)

This is the only way I could see to preserve any semblance of
backwards compatibility.  I really don't like it, though.  It would be
providing backwards compatibility at the expense of clarity and
simplicity.  In particular, the function d_bare_function_type in
cp-demangle.c would have to maintain a two type look-ahead.  Perhaps,
keeping the return type encoded as the first argument and separating
it from the rest of the argument list by a "v" could keep the
look-ahead logic isolated to the front of the function.

TJ


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