Re: MI: type prefixes for values

Eli Zaretskii
2006-02-17T14:11:06Z

> 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.

> > > In the output of print, the type of variable is sometimes wrapped in
> > > {}, sometimes in (), and there are no formal rules a frontend author
> > > can use to extract type from this information.
> >
> > The formal rules can be stated, if that's what is missing. The code
> > that produces the parentheses is deterministic, so the rules for when
> > they are used can be defined.
>
> Sure, they can be stated. But:
> - I don't think anobody is working on that

Volunteers are welcome.

> - 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?

> > 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.