Re: RFA: Switch TYPE_CODE_METHOD to store arguments like TYPE_CODE_FUNCTION

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, Jun 13, 2002 at 06:35:59PM -0500, Jim Blandy wrote:
> 
> Minor observation:
> 
> In gdbtypes.h, your patch makes the following change to `struct field':
> 
>      /* Name of field, value or argument.
> -       NULL for range bounds and array domains.  */
> +       NULL for range bounds, array domains, and member function
> +       arguments.  */
>  
>      char *name;
> 
> Is there any reason this *must* be null?  Aren't there times where we
> do know a method's arguments' names, and where we could fill this in?
> 
> I guess I'm thinking about the way prototyped function types in C may
> or may not include the names:
> 
>         typedef int (*foo_t) (int x, int y);
>         typedef int (*bar_t) (int, int);
>         typedef int (*baz_t) (int x, int);
> 
> Is there any analog to this in C++?

Right now, we have two entries for a method.  One of them is at
declaration time and comes from the class; the other is at definition
time and comes from the function itself.  One is TYPE_CODE_METHOD and
names are not present in the debug info for either stabs or dwarf; the
other is TYPE_CODE_FUNCTION.  Until we unify those (some day...) we
won't have the names.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer