Re: [Fwd: Re: [PING][PATCH][RFC] vterminate use of malloc-less demangler]

[Ian Lance Taylor <iant at google dot com>]

Benjamin Kosnik <bkoz@redhat.com> writes:

> What I think might be a better interface would be to allow the caller to
> provide "alloc" and "dealloc" functions (ala C++ allocators).  Then, the
> standard __cxa_demangle function would pass "malloc" and "free" for
> those parameters, while more sophisticated callers could pass functions
> that allocate out of a static buffer.  Or, a variant of cxa_demangle
> where we never try to "realloc" the buffer.
> 
> Never really answered directly.

Ben, that is really unfair.  I answered that: I said you can always
implement an allocation interface out of a callback interface, but the
reverse is not true.

I gave __vterminate as the obvious use for this sort of code, but not
the only one.

> Your answer instead seems to indicate that you think of the patch
> under consideration as only useful for vterminate.cc, and the
> resulting patch certainly supports this by keeping the poorly-named
> __gcclibcxx_demangle_callback private. (If functions are supposed to
> be named after what they do, then what does this function do?)

So please suggest a different private name.  The public interface to
the demangler plus callback is cplus_demangle_print_callback, declared
in demangle.h.  The __gcclibcxx_... name comes from the desire to
provide a mode in which cp-demangle.c only provides private names.
This mode has been implemented since cp-demangle.c was first written.
See the long comment at the top of cp-demangle.c.

> So, I guess I see this patch as a hack, and a useful hack at that, but
> just for vterminate.cc. This is unfortunate. And the continued
> side-stepping around the C++ maintainers desire for a better
> general-purpose solution is also unfortunate, (as is ignoring
> repeatedly the suggestions of previous interfaces and interface
> options), but not a good enough reason to keep useful hacks out of gcc.

Here's the thing: Simon has actually thought about these issues, and
discussed it with me.  You've asked for something different but you
haven't said what that should be.  If you want the patch to look
different, you need to make specific suggestions.

This solution is general.  A solution in which you pass an allocator
interface to the demangler is less general.  Think about it.

If you want libiberty to provide an allocation interface built on top
of the callback interface, that would be fine.  It would add another
layer of indirection to the use in __vterminate, but maybe it would
make __vterminate easier to understand.

I didn't suggest CC'ing the demangler patch to libstdc++ because
historically that has never been done.  The demangler has been handled
as part of libiberty.  Sorry about that.

> "All that opaque," huh? Aren't you already conceding the point here?

Callback interfaces are hardly unusual in C, and for good historical
reasons the demangler in written in C.

> However, I don't have the time at the moment to dedicate to the effort
> of designing something better, and won't until after April 21 at the
> earliest, plus emailing Simon is exhausting. So, do what you will.

OK, we'll just withdraw the patch until you or some other libstdc++
maintainer feels like looking at it.

I think Simon's pinging of the patch has been perfectly appropriate.

Ian