Re: -var-show-attributes response syntax

Vladimir Prus
2006-11-10T16:53:07Z

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