Re: [c++] Another question about demangler output

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Dec 06, 2003 at 09:08:49PM -0500, Ian Lance Taylor wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > Consider this program:
> > template<typename B> class BB { public: BB() { }
> >  typedef int (*foot)(void);
> >  operator foot () { return 0; }
> > };
> > 
> > BB<int> obj;
> > 
> > int foo()
> > {
> >   return ((int (*)(void)) obj) != 0;
> > }
> > 
> > One symbol generated by this program is _ZN2BBIiEcvPFivEEv, which demangles
> > as:
> >   BB<int>::operator int (*)()()
> 
> You don't need the template, of course.  You can get your irritating
> result with simply
> 
> class BB { typedef int (*foot)(void); operator foot (); };
> BB::operator foot() { return 0; }
> 
> This gives _ZN2BBcvPFivEEv which (currently) demangles as
>     BB::operator int (*)()()
> 
> But using a gcc extension, I can do this without a typedef:
> 
> class BB { operator typeof (int(*)())(); };
> BB::operator typeof (int(*)())() { return 0; }
> 
> So this suggests that the demangler should be changed.  When a
> conversion operator is used with a complex type, the demangler should
> demangle the name using `typeof'.

I'm OK with this.  It will require some change in GDB, because a
simplistic approach to parsing can handle the existing output (member
function?  named "operator " followed by a string that isn't an
operator name?  Must be a cast to STRING!).  But GDB and other
consumers can be fixed, and typeof resolves the ambiguity for my
purposes quite nicely.

It is my goal for this program to be idempotent on the output of the v3
demangler, i.e. to be able to build a parse tree that the demangler's
print functions will produce the input string from.  So far I'm fairly
close.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer