This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Remove deprecated_set_value_type
- From: "Rob Quill" <rob dot quill at gmail dot com>
- To: "Rob Quill" <rob dot quill at gmail dot com>, gdb-patches at sourceware dot org
- Date: Mon, 17 Dec 2007 09:12:37 +0000
- Subject: Re: Remove deprecated_set_value_type
- References: <baf6008d0711130201i20bae460r71d56216d0f02f38@mail.gmail.com> <20071113124021.GB22747@caradoc.them.org> <baf6008d0711130626x469603bck3da88de598cc614c@mail.gmail.com> <baf6008d0711131123h5a7d1521k11de4a1bab74e655@mail.gmail.com> <20071216204754.GF22905@caradoc.them.org>
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