Re: [RFC/RFA] Fix varobj.c value comparison problems

[Daniel Jacobowitz <drow@false.org>]

On Thu, Feb 17, 2005 at 09:31:50PM -0500, Mark Kettenis wrote:
> Here's a patch for the problems with uninitialized floating-point
> varobj stuff I reported a few days ago.  This patch introduces a new
> function value_contents_equal.  That part is pretty "obvious",
> although one might argue that it should be put in valarith.c.  I
> didn't put it there because this doesn't implement a C operator.
> 
> The patch then changes my_value_equal in varobj.c to use that new
> function.  I radically simplified the function.  I think these
> simplifications are justified.  The function is used to compare the
> old value of a variable with the new value of a variable.  Therefore
> the value of VAR1 should already be known.  I've put in a gdb_assert
> to make sure this is indeed the case.  So we only have to deal with
> unlazying VAR2.  Thus far, it seems that I'm right.  This patch fixes
> the problems I was seeing and doesn't introduce any new failures.
> 
> If nobody can shoot any holes in my reasoning, I'll check this in in a
> few days.

It sounds right to me.

> +  type1 = check_typedef (value_type (val1));
> +  type2 = check_typedef (value_type (val2));
> +  len = TYPE_LENGTH (type1);
> +  if (len != TYPE_LENGTH (type2))
> +    return 0;

Should we just require equal types?  I can't think of a real example,
but hypothetically, if we had a language with tagged unions:
  int kind;
  union { int a; float b; } u __attribute__((tagged(kind)))

and "kind" changed, thereby changing u from "0x80000000" to "whatever
that is as a single-precision float", the client would probably want to
update its display.

-- 
Daniel Jacobowitz
CodeSourcery, LLC