Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

["Ian Lance Taylor via binutils" <binutils at sourceware dot org>]

On Tue, Dec 11, 2018 at 3:05 AM Pedro Alves <palves@redhat.com> wrote:
>
> I noticed that the comment on top of __cxa_demangle says:
>
>   "If OUTPUT_BUFFER is not long enough, it is expanded using realloc."
>
> and __cxa_demangle calls 'free'.
>
> And d_demangle, seemingly the workhorse for __cxa_demangle says:
>
> /* Entry point for the demangler.  If MANGLED is a g++ v3 ABI mangled
>    name, return a buffer allocated with malloc holding the demangled
>    name.  OPTIONS is the usual libiberty demangler options.  On
>    success, this sets *PALC to the allocated size of the returned
>    buffer.  On failure, this sets *PALC to 0 for a bad name, or 1 for
>    a memory allocation failure, and returns NULL.  */
>
> cplus_demangle, the entry point that gdb uses, also relies on malloc.
>
> Ian earlier mentioned that we've wanted to avoid malloc because some
> programs call the demangler from a signal handler, but it seems like
> we already do, these functions already aren't safe to use from
> signal handlers as is.  Where does the "we can't use malloc" idea
> come from?  Is there some entry point that avoids
> the malloc/realloc/free calls?

cplus_demangle_v3_callback and cplus_demangle_print_callback.

Ian