From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12413 invoked by alias); 27 Feb 2008 22:07:22 -0000 Received: (qmail 12405 invoked by uid 22791); 27 Feb 2008 22:07:21 -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; Wed, 27 Feb 2008 22:07:01 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 49ACD98140; Wed, 27 Feb 2008 22:07:00 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 2C5EE9811F; Wed, 27 Feb 2008 22:07:00 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JUUQV-00077v-DU; Wed, 27 Feb 2008 17:06:59 -0500 Date: Wed, 27 Feb 2008 23:50:00 -0000 From: Daniel Jacobowitz To: Aleksandar Ristovski Cc: gdb-patches@sourceware.org Subject: Re: [patch] fix for c++/2416 Message-ID: <20080227220659.GE14556@caradoc.them.org> Mail-Followup-To: Aleksandar Ristovski , gdb-patches@sourceware.org References: <47C5A5EE.6070107@qnx.com> <20080227193546.GA11796@caradoc.them.org> <47C5BE84.7050803@qnx.com> <20080227200019.GB12434@caradoc.them.org> <47C5D138.6020909@qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47C5D138.6020909@qnx.com> 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: 2008-02/txt/msg00459.txt.bz2 On Wed, Feb 27, 2008 at 04:08:08PM -0500, Aleksandar Ristovski wrote: > 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). This arises from the C language standard coercions, more or less. It is supposed to be called with references, functions, pointers, et cetera. If you give it an array, it gives you back a pointer to the first element; the same if you do it with a reference to an array. > 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. No, we try to treat them as the thing referenced-to, not the pointer doing the referencing. This is to be consistent with the languages we're evaluating. Expression evaluation and printing goes wrong if you don't. > 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). value_as_address on a reference is supposed to referenced value as an address, not the pointer value stored in the reference. It's probably the caller of value_as_address which is mistaken. -- Daniel Jacobowitz CodeSourcery