This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] MI: lvalues and variable_editable
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Vladimir Prus <ghost at cs dot msu dot su>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 1 Nov 2007 17:51:58 +1300
- Subject: Re: [PATCH] MI: lvalues and variable_editable
- References: <18210.27153.559569.601092@kahikatea.snap.net.nz> <200710301222.03459.ghost@cs.msu.su> <18215.4053.151140.671560@kahikatea.snap.net.nz> <200710311458.58112.ghost@cs.msu.su>
> 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.
--
Nick http://www.inet.net.nz/~nickrob