This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Support the new demangler written in C++
Alex wrote:
> Anything that changes libiberty would require agreement from DJ, and
> he'd probably want feedback from the many projects that happen to
> use libiberty nowadays, often for completely unrelated purposes.
Most of those projects don't have a C++ requirement, either. I don't
expect them to be happy about needing a C++ compiler just to build a
portability layer for their C programs.
H.J. wrote:
> I'd like a yes or no answer.
I'm still inclined to say "no". As the libiberty maintainer, my goals
for libiberty relevent to this are:
1. Libiberty should be self-contained.
This is mostly because there are so many projects using
libiberty that it's impractical to expect them all to
suddently start pulling in an entirely new source tree just to
have a working libiberty.
2. Libiberty's functionality should be independent of the build
environment.
This is because libiberty is, fundamentally, a portability
library. Its whole purpose is to provide the exact same
functionality independent of the build environment. Note that
the build environment includes the compiler - requiring a C++
compiler means it's less independent, since not all
environments have a C++ compiler.
If there were no other way to include a demangler and still meet these
goals, I might be persuaded to bend the rules, or perhaps kick the
demangler out of libiberty. But libiberty *has* a demangler that
meets these rules - it just happens to have a bug in it. I can't
justify (nor has anyone else justified) breaking the rules just
because nobody has bothered to fix the existing demangler, and this
continuing discussion about all the things that could go wrong just
makes it more obvious that hacking in the C++ demangler is the wrong
thing to do.