Re: -var-show-attributes response syntax

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

Nick Roberts wrote:

> Vladimir Prus writes:
>  > 
>  > Hello!
>  > 
>  > Here's the docs for -var-show-attributes MI command:
>  > 
>  >        Synopsis
>  >             -var-show-attributes name
>  > 
>  >           List attributes of the specified variable object name:
>  >              status=attr [ ( ,attr )* ]
>  >              where attr is { { editable | noneditable } | TBD }.
>  > 
>  > What is the reason for using "non" instead of
>  > "attribute_name=attribute_value" syntax? The above assumes all
>  > attributes are boolean, which is not very extensible.
> 
> I think the above means output may be something like:
> 
> ^done,attr={"editable","yellow","big"}

Yes, and this is exactly what I'm objecting too. 

> (Perhaps { a | b } should be documented in "Notation and Terminology".)
> 
> Currently it appears that attr="noneditable" for constant types and
> attr="editable" otherwise.  I don't know what other attributes the authors
> had in mind (long?, volatile?, local?, static?).
> 
>  > How about changing the above to "editable=0/1"?
> 
> 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.

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

- Volodya