From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19959 invoked by alias); 27 Feb 2008 21:08:29 -0000 Received: (qmail 19951 invoked by uid 22791); 27 Feb 2008 21:08:28 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO qnxmail.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 27 Feb 2008 21:08:11 +0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.42.96.5]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id PAA11206; Wed, 27 Feb 2008 15:51:22 -0500 Received: from [10.42.100.129] (dhcp-100-129 [10.42.100.129]) by smtp.ott.qnx.com (8.8.8/8.6.12) with ESMTP id QAA24394; Wed, 27 Feb 2008 16:08:08 -0500 Message-ID: <47C5D138.6020909@qnx.com> Date: Wed, 27 Feb 2008 21:26:00 -0000 From: Aleksandar Ristovski User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sourceware.org Subject: Re: [patch] fix for c++/2416 References: <47C5A5EE.6070107@qnx.com> <20080227193546.GA11796@caradoc.them.org> <47C5BE84.7050803@qnx.com> <20080227200019.GB12434@caradoc.them.org> In-Reply-To: <20080227200019.GB12434@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-02/txt/msg00455.txt.bz2 Daniel Jacobowitz wrote: > > For expressions, casting one reference to another is OK; casting a > reference to a non-reference is also fine. Only non-reference to > reference is trouble. > >>> The new error is incorrect, which does suggest some missing tests. >>> You can cast from a reference type; value_cast follows references, >>> so an int is just like an int &. >>> >>> Like Michael, I don't understand the value.c changes. Could you >>> explain them? >>> >> I replied to that. > > What about the changes to coerce_array? > I haven't made any changes to coerce_array itself, only made sure we do not call it if it's not an array. But I find its implementation somewhat confusing: it looks like it can be called with all kinds of TYPE_CODE for the arg... if that is correct than the name is misfortunate... and if not, then we should determine why is it being called with TYPE_CODE_REF (my patch eliminates one place where this is being done). Another thing that confuses me is such a special treatment for references to something... in my mind, (talking about C++) we should be able to internally treat them as pointers to that something. For example, in the fix I provided if you comment out //if (TYPE_CODE (value_type (val)) == TYPE_CODE_ARRAY) in value.c:1042 (after applying my patch) it will call, as without the patch, coerce_array; then if you follow to coerce_ref you will see that after coerce_ref, address is messed up causing printing garbage (no surprise since the address is wrong). Unfortunately I do not have time at the moment to get any deeper than this, but I will reiterate (and please feel free to enlighten me with the reasons) that I do not see reasons for treating TYPE_CODE_REF in a different way than TYPE_CODE_PTR.