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

Benjamin Kosnik bkoz@redhat.com
Wed Mar 28 09:39:00 GMT 2007


> Honest, we already thought about the C API.  And we already discussed
> it over here when it went in:
> 
> http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01116.html

Ahh. I'd missed this.

FYI Simon this should have been posted to libstdc++ list. Please make a 
point of cc'ing the libstdc++ list on libstdc++ issues in the future.

I see Mark had the same qualms I have about this.

ie:

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.

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, 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.

> I don't think it's all that opaque, and I believe it's actually well
> designed for the problem.

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

The specified problem area is incorrect, IMHO.

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.

:(

-benjamin



More information about the Libstdc++ mailing list