Re: [PATCH] MI: lvalues and variable_editable

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

On Thursday 01 November 2007 07:51:58 Nick Roberts wrote:
>  > On Tuesday 30 October 2007 14:04:53 Nick Roberts wrote:
>  > >  > 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.
>  > 
>  > As long there which code *replaces* gdb_evaluate_expression, I'm 
>  > perfectly happy. Thanks!
> 
> Using var->value == NULL means that variable objects of pointers that cannot
> be dereferenced are "noneditable".  This means that such variable objects
> may change from being "editable" to "noneditable" during execution.  This
> may not be a bad thing as discussion started from posts about not being
> able to assign values to variable objects that were described as "editable".
> 
> I'll look at combining varobj_editable_p with the test in
> mi_cmd_var_assign:
> 
>   if (!varobj_set_value (var, expression))
>     error (_("mi_cmd_var_assign: Could not assign expression to variable object"
> 
> to give one message.

I'm not sure that's possible. If you create varobj for *foo, and foo changes
to point to inaccessible memory, then assignment to *foo will fail, but I
don't know any mechanism in gdb that will tell you that without actually
trying assignment.

- Volodya