Yes, we now use a larger buffer.  But on second thought it’s still a fixed size buffer, so although no existing compiler will ever generate a symbol that could crash it anymore, a fuzzer could.  I’ll fix it even better tomorrow <br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 29, 2018 at 5:23 PM Friedman, Eli <<a href="mailto:efriedma@codeaurora.org">efriedma@codeaurora.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8/29/2018 4:56 PM, Zachary Turner via llvm-commits wrote:<br>
>    * Account for "incorrect" string literal demanglings.  Apparently<br>
>      an older version of clang would not truncate mangled string<br>
>      literals to 32 bytes of encoded character data.  The demangling<br>
>      code however would allocate a 32 byte buffer thinking that it<br>
>      would not encounter more than this, and overrun the buffer.<br>
>      We now demangle up to 128 bytes of data, since the buggy<br>
>      clang would encode up to 32 *characters* of data.<br>
<br>
It sounds like this was this a crash?  If so, did you fix the crash?<br>
<br>
-Eli<br>
<br>
-- <br>
Employee of Qualcomm Innovation Center, Inc.<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br>
<br>
</blockquote></div>