Re: [RFA] handling of 'operator' in cp_find_first_component

[David Carlton <carlton@math.stanford.edu>]

On Mon, 21 Apr 2003 23:21:52 -0400, Daniel Jacobowitz <drow@mvista.com> said:

> As Daniel Berlin pointed out, the demangler is behaving correctly.
> The return type is part of the mangled signature in this case, and
> must be.

I'm actually curious why it must be, but that's another issue; it
simply is the case that it's part of the mangled signature, so the
demangler is behaving correctly.

> However, for GDB's purposes, is it _necessary_ or _useful_ to have
> said mangled name?  If not, for another project I already have a
> cplus_demangle wrapper which plays with the resulting names.
> Adapting it to detect and remove return types would probably be
> easy.

I suspect that it's not useful (I'll talk more about that downthread);
whether or not it's useful, I'm pretty sure that, right now, it's
actively harmful.  We have code in GDB that deals with function names;
that code assumes that the function names doesn't have certain
characteristics.  So if the demangler is returning "int foo<int>(int)"
then I bet that "break foo<int>" doesn't work for us.

I would be tempted to put the code to not give return types in the
demangler itself, though, rather than in a post-processor: that seems
to me to be more reliable and more efficient.

> I am not strong in this area of C++, but as far as I know this should
> suffice; the demangled name of such a function will always include the
> template parameters; and the template-id must be unique in the program
> (right?  Not sure if the ODR comes into play here or not) so either
> there is only one possible return value or the template parameters
> uniquely identify the return value.

> i.e. you can't have a program with
>   int foo<int> (int)
> and
>   long foo<int> (int)
> in it!

That's my attitude, too.  Template parameters and argument types can
distinguish functions; return types can't.  At least I assume so; on
the other hand, presumably the ABI authors had a reason for including
return types in the demangled name in this situation.  But even if
there are some strange boundary cases where it's necessary to
disambiguate functions, I still think that, right now, GDB is much
more likely to be hurt than to be helped by having return types in
there.

> That said, I still think your patch is OK; on the condition that it
> handles the test case the comment you're removing refers to.  Something
> like:
>   int foo<operator() (B&)>
> or whatever it was in the right syntax.  Does it, and can you add that
> to the maint.exp tests?

It should handle them, but you're right, I should include such
examples in the maint.exp tests.  I'll go off and generate some
examples first before checking it in.

David Carlton
carlton@math.stanford.edu