Re: MI: type prefixes for values

[Vladimir Prus <ghost@cs.msu.su>]

On Friday 17 February 2006 17:10, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 17 Feb 2006 16:58:22 +0300
> > Cc: gdb@sources.redhat.com
> >
> > > > It's only avaiable in tooltip text for a variable. So far, no
> > > > complaints.
> > >
> > > I don't see how is this contrary to what GDB assumes.  GDB passes the
> > > information to the front end; how the front end displays it, is
> > > entirely up to the front end.
> >
> > Because for display in variable tree, frontend prefers not to show any
> > type, and for display in varible tooltips, it prefers to show the type
> > after the value, not before.
>
> That's quite specific to that front end, right?  We cannot possibly
> assume they all will behave like that.

Exactly. Then why format value in a specific way that suites some frontends, 
but not others.

> > - The parsing of that value will have to be done by ad-hoc code, which is
> > contrary to MI-goal of being easily parsable.
>
> Why ad-hoc? if you have {}, parse it, if not, don't.  Why is this
> simple rule hard for a parser?

Here's the relevant part from KDevelop:

  if (*start == '{')
    {
        // Gdb uses '{' in two cases:
        // - composites (arrays and structures)
        // - pointers to functions. In this case type is
        //   enclosed in "{}". Not sure why it's so, as
        //   when printing pointer, type is in parenthesis.
        if (type == typePointer)
        {
            // Looks like type in braces at the beginning. Strip it.
            start = skipDelim(start, '{', '}');
        }
        else
        {
            // Looks like composite, strip the braces and return.
            return QCString(start+1, end - start -1);
        }

You see, if I strip everything {}-enclosed at the beginning of value, I'll 
never show any structures. And how do I decide if the value is a pointer, or 
structure? That code was written before me, and is 100 lines in size.

And the only way to reliably tell if a variable is a pointer or not is to 
issue -var-type-info, which, according to you, is not necessary if there's {} 
in the value. Or I might look after the closing brace and see if there's 
anything there, which starts to look pretty hacky.

> > > Then perhaps we should add the type info to all arguments, instead of
> > > removing it from where it exists now.
> >
> > It might be good idea, but why don't add it as a separate field? I.e.
> > instead of
> >
> >   ^done,value="(int *) 0x0"
> >
> > you'll get
> >
> >   ^done,value="0x0",type="int *"
>
> Fine with me.

So, are patches to the effect of removing type from value, and moving it to a 
separate field welcome?

- Volodya