Re: [PATCH][RFC] Malloc-less demangler interface

[Mark Mitchell <mark at codesourcery dot com>]

Ian Lance Taylor wrote:

>> 2. The reliance alloca means that on some systems you may exceed stack
>> limits.  Some systems may have rather small stacks and some mangled
>> names are big.  So, while you're reducing reliance on malloc, you're
>> increasing reliance on alloca.
> 
> Note that alloca is only used for targets which do not support
> dynamically allocated arrays.  That is, it is only used for C89 (not
> C99) compilers which are not gcc.  In particular, for the interesting
> case of the demangler included in libsupc++, the demangler is always
> compiled by gcc and will never use alloca.

OK.

>> In other words, it seems to me we should focus on the allocation
>> interface, rather than creating a "stream" interface, which is what your
>> approach does.  The only argument I can see in favor of the stream
>> interface is that it would allow you to print a demangled name via
>> write(2) even when you had no space (dynamic or otherwise) to hold the
>> mangled name.
> 
> The stream interface is particularly interesting in the particular
> case of vterminate or signal handlers, where we may not have any
> reliable memory allocation routine.

So, is the case of interest the one I was mentioning above?  In
particular, in your crash handler, you want to pass "write" (or some
thin wrapper for it) to the demangler and just stream out the demangled
name to some log file and/or stderr?

If so, then I understand the goal, though, frankly, I'd just write the
mangled name, since if the program is dying a horrible death, you may
not have much of anything working reliably at this point.  Or, at least,
I'd write the mangled name first, before trying bravely to demangle it. :-)

In any case, if I understand the goal correctly, I'm OK with the concept
of the patch, given the clarification about alloca.  Since you were
already reviewing it, I'll let you do the nit-picking for comments and
style. :-)

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713