This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: c++/1245: cp-support.c:332: internal-error:cp_entire_prefix_len
- From: David Carlton <carlton at kealia dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 30 Jun 2003 16:18:00 -0000
- Subject: Re: c++/1245: cp-support.c:332: internal-error:cp_entire_prefix_len
- Reply-to: David Carlton <carlton at kealia dot com>
The following reply was made to PR c++/1245; it has been noted by GNATS.
From: David Carlton <carlton@kealia.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: GNATS Filer <gdb-gnats@sources.redhat.com>
Subject: Re: c++/1245: cp-support.c:332: internal-error:
cp_entire_prefix_len
Date: Mon, 30 Jun 2003 09:14:15 -0700
On 19 Jun 2003 16:58:01 -0000, Daniel Jacobowitz <drow@mvista.com> said:
> Hm, we might be able to handle this - at least for some cases.
> "operator <<" should always be followed by either a template
> instantiation or an argument list. If we see "operator <<<"
> or "operator "<< " then we have operator <<; template args will not
> start with a space or an angle bracket.
> "operator <<(" is actually ambiguous:
> operator <<(char)1>(foo, bar) is operator <
> operator <<(char, bar) is operator <<
> However, we could take advantage of the fact that both operator < and
> operator << are binary operators, and scan for a toplevel comma
> following that parenthesis. I think that would suffice.
I don't think that's the right way to go. Parsing C++ is a hard
enough problem; figuring out the intended meaning of illegal C++ is,
it seems to me, something that we should avoid whenever possible. So
I'd much rather have the demangler produce legal C++.
Having said that, it also seems to me that the band-aid that I'm about
to commit is a reasonable medium-term fix, so I'm not too worried
about this one way or another.
David Carlton
carlton@kealia.com