From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21342 invoked by alias); 16 Dec 2007 20:48:04 -0000 Received: (qmail 21334 invoked by uid 22791); 16 Dec 2007 20:48:03 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 16 Dec 2007 20:47:57 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id E8B5F9814F; Sun, 16 Dec 2007 20:47:55 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id B754C9811F; Sun, 16 Dec 2007 20:47:55 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J40Ow-00009x-VS; Sun, 16 Dec 2007 15:47:54 -0500 Date: Sun, 16 Dec 2007 20:50:00 -0000 From: Daniel Jacobowitz To: Rob Quill Cc: gdb-patches@sourceware.org Subject: Re: Remove deprecated_set_value_type Message-ID: <20071216204754.GF22905@caradoc.them.org> Mail-Followup-To: Rob Quill , gdb-patches@sourceware.org References: <20071113124021.GB22747@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-11) 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/msg00220.txt.bz2 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? -- Daniel Jacobowitz CodeSourcery