From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2741 invoked by alias); 17 Dec 2007 09:12:45 -0000 Received: (qmail 2733 invoked by uid 22791); 17 Dec 2007 09:12:44 -0000 X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.176) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Dec 2007 09:12:39 +0000 Received: by wa-out-1112.google.com with SMTP id l35so3371442waf.12 for ; Mon, 17 Dec 2007 01:12:37 -0800 (PST) Received: by 10.115.106.7 with SMTP id i7mr2589413wam.18.1197882757499; Mon, 17 Dec 2007 01:12:37 -0800 (PST) Received: by 10.114.102.11 with HTTP; Mon, 17 Dec 2007 01:12:37 -0800 (PST) Message-ID: Date: Mon, 17 Dec 2007 10:40:00 -0000 From: "Rob Quill" To: "Rob Quill" , gdb-patches@sourceware.org Subject: Re: Remove deprecated_set_value_type In-Reply-To: <20071216204754.GF22905@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071113124021.GB22747@caradoc.them.org> <20071216204754.GF22905@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00261.txt.bz2 On 16/12/2007, Daniel Jacobowitz 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