Re: [PATCH] MI: lvalues and variable_editable

[Nick Roberts <nickrob at snap dot net dot nz>]

 > I believe that var->value will be NULL.

Yes, that looks good.  I'll use:

  if (!var->value || !VALUE_LVAL(var->value))
    return 0;

and that should keep us both happy.

 > > When it's created it can be in a different frame according to the syntax.
 > > However, in Emacs I only create watch expressions in the selected frame
 > > (the manual suggests that "*" sets the value in the current frame but
 > > there are many anomalies like this).
 > 
 > Are you suggesting that GDB code should only work when used from Emacs? 

If I was, I would probably say something like "I suggest that GDB code should
only work when used from Emacs".  You're free read it how you like, but I was
just giving an example of real use.

 >                                                                        GDB,
 > as it stands, allows you to create a variable object in any frame, and your
 > patch does not work with that. So, either creating variable objects in any
 > frame should be disallowed, 

Actually I think that would be a good idea.  Generally a user would create a
watch expression in the frame he's examining.  If not, the frontend would have
to prompt for the frame.  Does KDevelop do this?

 >...
 > > Likewise I think variable assignment should only be done in the selected
 > > frame.
 > 
 > Err, why? I might have varobj for global variable called like 'g'. When I
 > assign value to that varobj, I don't really want any local variable called
 > 'g' to get in.  Of course, real program would have the variable named
 > differently, but still.

I'm not talking about global variables as they're valid in all frames.

 >...
 > > That's what I've just said.
 > 
 > So, in essence, the primary think you test is that this message now
 > say "Variable object is not editable"?

It's not just the message but that it's now triggered by:

  if (!(varobj_get_attributes (var) & 0x00000001))

instead of:

  if (!varobj_set_value (var, expression))

 > I personally think that the fact that -var-show-attributes reports rvalues
 > as non-editable is equally important, but if you don't feel like writing a
 > test for that, up to you -- in which case I'll probably submit a patch
 > myself (and maybe even make the 'editable' field into regular varobj
 > printing, as opposed to this 'attribute' thing).

mi_cmd_var_show_attributes calls varobj_get_attributes.  Like I said:
it's basically the same test.

-- 
Nick                                           http://www.inet.net.nz/~nickrob