This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ demangler horrors


Phil Edwards <phil@jaj.com> writes:

> On Fri, Jun 27, 2003 at 11:03:37PM +0200, Gabriel Dos Reis wrote:
>> "H. J. Lu" <hjl@lucon.org> writes:
>> | 
>> | It will be used for libiberty, not libstdc++-v3.
>> 
>> I'm not a big fan of code duplication.  Having to maintain two 
>> implementations of the demangler is not something I would recommand.

FWIW, I agree.

> Exactly.  More to the point, we have yet to find a volunteer to maintain
> the /new/ new demangler.  It would be discourteous to expect Carlo to
> maintain both the real demangler as well as this "adapted" one.
>
> Someone has volunteered to write or submit miniature versions of string
> and vector, but I haven't heard whether he also plans to maintain those.

On the context of GCC? Yes, I'll maintain the minivector.

The real crux of this issue is that the demangler is targeted to
binutils and gdb as well. People building those packages have
good-knows-what C++ compiler, in the case they have a C++ compiler at
all. My minivector and the demangler implementation are far from being
"arcane" C++, but there are still too many broken compilers out there.

Another issue is: what can I do when someone using the stock
AIX/HPUX/Solaris/whatever C++ compiler reports a bug? I don't have
every C++ compiler under the sun to test, nor I wish to test every
past gcc release starting from the dark ages.

A C++ demangler is ok for the GCC package, but a can of worms for
binutils and gdb.

[snip]

-- 
Oscar


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]