<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 23 Jan 2019, at 15:48, Duncan Exon Smith wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">+John and Nick<br>
<br>
I'm not sure this is the right thing to do.<br>
<br>
I believe there was an intentional decision way back when (before my time) to require clients to strip the leading underscore. c++filt on my desktop does this (passing `-_` by default, which means symbols without the leading underscore don't get demangled).<br>
<br>
Nick and John, do you have any recollection of why the demangler was restrictive like this? Any thoughts on whether it's problematic to relax it?</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Okay. If you step back and consider the whole operation of taking a string, figuring out whether it's a C++ mangled name, and then trying to demangle it, there is a plausible reason why you might not want to accept <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__Z</code> as a prefix: it permits an algorithm which, when followed by clients on leading-underscore targets, reliably avoids demangling unreserved C function names like <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Z3zapEv</code>. If clients can present you with either a stripped or unstripped name, then it's ambiguous whether <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">_Z3zapEv</code> is a stripped reserved name (hence okay to demangle) or an unstripped unreserved name (hence not okay to demangle). If clients on leading-underscore targets can be trusted to first find and remove the leading underscore, and to just not call you if there's no leading underscore, this problem resolves itself. Not allowing <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__Z</code> as a prefix therefore encourages clients to implement the logic correctly so that you can get the corner cases right.</p>
<p dir="auto">On the other hand, you can make a strong argument that the only prefix which matters is the complete prefix on symbol names, so that the right way of thinking about it is that the C++ mangling prefix is <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__Z</code> instead of <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">_Z</code> on leading-underscore targets; certainly this leads to a more reasonable conceptual model in the face of languages like Swift that eschew the underscore on all targets. But actually following that logic would mean that the demangler would need to have target-specific behavior, and no tooling using the demangler is set up to propagate target information down (and what would that mean for c++filt anyway?).</p>
<p dir="auto">In practice it's incredibly frustrating that <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">c++filt</code> doesn't allow an actual symbol name on the command line, although arguably this is a usability problem with <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">c++filt</code> rather than a flaw in the lower-level interface.</p>
<p dir="auto">But none of that really matters. This patch is a change to a function that's basically implementing (the first half of) <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__cxa_demangle</code>, and it's already inappropriate to call <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__cxa_demangle</code> in a generalized symbol-demangling use case with a non-C++ symbol name because <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__cxa_demangle</code> is required to try to demangle anything that doesn't start with <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">_Z</code> as a type. Since <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__Z</code> is not and will never be the start of a valid type mangling, it should be harmless to change <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__cxa_demangle</code> to also recognize a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">__Z</code> prefix, and it does permit clients to more comfortably adopt that better conceptual model for the nature of the C++ prefix.</p>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>