Re: RFC: MI - Detecting change of string contents with variable objects

[Nick Roberts <nickrob@snap.net.nz>]

 > > + 	      char* print_value = value_get_print_value (value, var->format);
 > 
 > Use "char *print_value", please.

OK.
 
 > >   	      gdb_assert (!value_lazy (var->value));
 > >   	      
 > > ! 	      if (var->print_value)
 > > ! 		{
 > > ! 		  if (strcmp (var->print_value, print_value))
 > > ! 		    {
 > > ! 		      xfree (var->print_value);
 > > ! 		      var->print_value = print_value;
 > > ! 		      changed = 1;
 > > ! 		    }
 > > ! 		}
 > > ! 	      else
 > > ! 		var->print_value = print_value;
 > 
 > Should we set changed = 1 in the "else"?

No.  This is only reached in the initial call to install_new_value i.e
-var-create.

 > Otherwise the patch seems fine, if it tests OK, but I'm still a little
 > nervous about it.  For example, you'll call val_print on a struct
 > or array to see if it's changed.  Depending on things like "set print
 > elements", that might not print out the whole string.  This is
 > probably a behavior change.  Is it a harmless one?  If it is, then
 > should we be sharing the code with c_value_of_variable that avoids
 > printing structs, unions, and arrays, and never mark them as changed
 > unless their types change?

The function val_print is already used for -var-evaluate-expression.  AFAICS
"set print elements" has no effect on variable objects, perhaps because
val_print is only called on the leaves but I can see that using it might
expose MI to the vagaries of CLI.  Currently, however, string changes don't
get reported at all, without the user changing configuration values.


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