This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Remove deprecated_set_value_type


On 16/12/2007, Daniel Jacobowitz <drow@false.org> 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
> c-valprint.c.
>
>               /* 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;
>               temparg=value_copy(val);
>               deprecated_set_value_type (temparg, lookup_pointer_type (TYPE_TARGET_TYPE(type)));
>               val=temparg;
>
> 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.

Rob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]