Mon Dec 17 10:40:00 GMT 2007
On 16/12/2007, Daniel Jacobowitz <email@example.com> wrote:
> On Tue, Nov 13, 2007 at 07:23:18PM +0000, Rob Quill wrote:
> > Is it a correct solution to add a function something like
> > copy_val_except_type, which copies all the fields from a value struct
> > except the type? So an new value is created of the right type, then
> > cop_val_except_type is called, which would replace the other fields.
> Sorry for losing this message. That may be right, but only for some
> of the calls. The trick is to consider not just what the effect of
> the current calls is, but what this means in terms of the abstraction
> of a "struct value". Does it make sense to change the type of a value
> without changing anything else about it? In a few cases yes, but
> not usually.
> I picked one call to deprecated_set_value_type; the one in
> /* Copy value, change to pointer, so we don't get an
> * error about a non-pointer type in value_rtti_target_type
> struct value *temparg;
> deprecated_set_value_type (temparg, lookup_pointer_type (TYPE_TARGET_TYPE(type)));
> There's a better way to do this: value_addr of a reference becomes
> a pointer to the same object. Of course, I see that the body of
> value_addr does it the same way as this code, using the
> deprecated method. So this call should use value_addr and the
> implementation of value_addr probably needs a new method that
> doesn't exist yet. I suggest "value_copy_and_change_type".
> To pick another example, printcmd.c uses it to do unchecked
> conversions from integers to bit patterns of floating point numbers -
> much to my surprise! I had no idea this was there until I read the
> code. Assuming we want to keep that behavior, the right way
> is not to smash the type of some existing value; instead, use
> value_zero (not_lval) to create a new value, and copy the
> bit pattern into it.
> Does that make sense?
Yep, I think so :) I'll look into this later today or tomorrow.
More information about the Gdb-patches