This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB 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++/1245: cp-support.c:332: internal-error:cp_entire_prefix_len


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


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