Re: -var-show-attributes response syntax

[Vladimir Prus <vladimir@codesourcery.com>]

On Friday 10 November 2006 23:43, Nick Roberts wrote:
>  > > I see no advantage in restricting the output but I've not used this
>  > > command. How do you want to use it?
>  >
>  > I want to add a new attribute there, actually, and I'd prefer to use
>  > more regular name=value syntax.
>
> That's still a bit vague.
>
> You say:
>
>    How about changing the above to "editable=0/1"?
>
> Are you suggesting
>
>   ^done,attr="editable=0",  ^done,attr="editable=1"
>
> or
>
>   ^done,editable="0",  ^done,editable="1"

The latter.

> Either case still requires the front end to do some string
> manipulation/comparison. 

I don't follow -- every syntax requires some string manipulation. In 
fact, "name=value" syntax is used in many other places so frontend already 
knows how to parse it.

> Can you state precisely how you would change the 
> format and precisely what the benefit would be?

The benefit is consistency with other MI response.

>  > >  >                                                 This sounds like
>  > >  >                                                 breaking
>  > >  > backward compatibility, but probably is not, because "editable" is
>  > >  > broken itself:
>  > >  >
>  > >  >      -var-create C * 1+1
>  > >  >      ^done,name="C",numchild="0",type="long"
>  > >  >      (gdb)
>  > >  >      -var-show-attributes C
>  > >  >      ^done,attr="editable"
>  > >  >      (gdb)
>  > >
>  > > Why do you think this is broken?
>  >
>  > Because you can't assign the value to "1+1" -- it's not lvalue. And
>  > trying to do so will result in error from gdb.
>
> I see, I missed that.  In fact it my example was also wrong too, constants
> in C appear to be editable.  Noneditables appear to be arrays, structures,
> unions etc.  However I think this a separate issue to changing the syntax.

I meant to say that this command does not seem to have useful semantic, so 
backward compatibility is not that important with it.

- Volodya