From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8794 invoked by alias); 17 Jan 2008 08:06:04 -0000 Received: (qmail 8783 invoked by uid 22791); 17 Jan 2008 08:06:02 -0000 X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.177) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Jan 2008 08:05:43 +0000 Received: by wa-out-1112.google.com with SMTP id l35so927993waf.12 for ; Thu, 17 Jan 2008 00:05:42 -0800 (PST) Received: by 10.115.107.1 with SMTP id j1mr2096209wam.55.1200557142088; Thu, 17 Jan 2008 00:05:42 -0800 (PST) Received: by 10.114.92.3 with HTTP; Thu, 17 Jan 2008 00:05:42 -0800 (PST) Message-ID: Date: Thu, 17 Jan 2008 08:06:00 -0000 From: "Rob Quill" To: "Rob Quill" , gdb-patches@sourceware.org, "Daniel Jacobowitz" 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: 2008-01/txt/msg00432.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? Hi Daniel, I've been working my way through the cases where deprecated_set_value_type is used, and am reasonably sure (pending testing) that I have removed them in the right way. However, I a unsure about this case from eval.c /* Let us now play a dirty trick: we will take arg1 which is a value node pointing to the topmost level of the multidimensional array-set and pretend that it is actually a array of the final element type, this will ensure that value_subscript() returns the correct type value */ deprecated_set_value_type (arg1, tmp_type); return value_ind (value_add (value_coerce_array (arg1), arg2)); I'm not sure how to handle this as I'm not really sure what it is doing. Intuitively it seems that using a "dirty trick" is a bad idea so maybe now might be the time to find a better way of doing this now while we're sorting out other things. I was just wondering if you had any suggestions or advice? Thanks. Rob