From: "Rob Quill" <rob.quill@gmail.com>
To: "Rob Quill" <rob.quill@gmail.com>, gdb-patches@sourceware.org
Subject: Re: Remove deprecated_set_value_type
Date: Mon, 17 Dec 2007 10:40:00 -0000 [thread overview]
Message-ID: <baf6008d0712170112l280309cu53bddc7a369954c7@mail.gmail.com> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2007-12-17 9:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-13 10:01 Rob Quill
2007-11-13 12:40 ` Daniel Jacobowitz
2007-11-13 14:26 ` Rob Quill
2007-11-13 19:23 ` Rob Quill
2007-12-16 20:50 ` Daniel Jacobowitz
2007-12-17 10:40 ` Rob Quill [this message]
2008-01-17 8:06 ` Rob Quill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=baf6008d0712170112l280309cu53bddc7a369954c7@mail.gmail.com \
--to=rob.quill@gmail.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox