From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25488 invoked by alias); 11 Mar 2009 18:37:01 -0000 Received: (qmail 25475 invoked by uid 22791); 11 Mar 2009 18:37:00 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Mar 2009 18:36:55 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2BIaSeH030124; Wed, 11 Mar 2009 14:36:29 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2BIaSB3019055; Wed, 11 Mar 2009 14:36:28 -0400 Received: from opsy.redhat.com (vpn-12-67.rdu.redhat.com [10.11.12.67]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2BIaROD016180; Wed, 11 Mar 2009 14:36:27 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 97DF7888546; Wed, 11 Mar 2009 12:36:25 -0600 (MDT) To: Joel Brobecker Cc: Mark Kettenis , jan.kratochvil@redhat.com, drow@false.org, gdb-patches@sourceware.org Subject: Re: [patch] Fix `return' of long/long-long results with no debuginfo References: <20090211214646.GA22247@host0.dyn.jankratochvil.net> <200902112157.n1BLvplk011339@brahms.sibelius.xs4all.nl> <20090211220824.GA26040@host0.dyn.jankratochvil.net> <200902112237.n1BMbbOb006035@brahms.sibelius.xs4all.nl> <20090211225012.GA28683@host0.dyn.jankratochvil.net> <200903042129.n24LTUKa000770@brahms.sibelius.xs4all.nl> <20090309015510.GA28986@host0.dyn.jankratochvil.net> <200903092233.n29MXEfG019900@brahms.sibelius.xs4all.nl> <20090311163024.GA25708@adacore.com> From: Tom Tromey Reply-To: Tom Tromey Date: Wed, 11 Mar 2009 20:23:00 -0000 In-Reply-To: <20090311163024.GA25708@adacore.com> (Joel Brobecker's message of "Wed\, 11 Mar 2009 09\:30\:24 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-03/txt/msg00158.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: >> 2009-03-09 Jan Kratochvil >> >> * stack.c (return_command ): New variables retval_expr >> and old_chain. Inline parse_and_eval to initialize retval_expr. Check >> RETVAL_EXPR for UNOP_CAST and set RETURN_TYPE to the RETURN_VALUE type >> if RETURN_TYPE is NULL. Joel> This looks good to me, but I don't understand the error message when Joel> the user forgot to cast the result. I wonder if we shouldn't just Joel> preserve the old behavior which is to implicitly cast to "int"? We've come full circle :-) The original patch was motivated by a case where casting to int gave a bad result. Then Mark had a counter-proposal, which was to use the expression's type, rather than assuming 'int'. Finally, I suggested simply requiring a cast, resulting in this patch. So, the real question for you is how you think it ought to work. I think we have implementations of all of the approaches now. Tom