From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29232 invoked by alias); 24 Jan 2008 01:30:52 -0000 Received: (qmail 29221 invoked by uid 22791); 24 Jan 2008 01:30:51 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Jan 2008 01:30:34 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C69302A9663; Wed, 23 Jan 2008 20:30:32 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mPVb80cN3RAF; Wed, 23 Jan 2008 20:30:32 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 8E7352A9660; Wed, 23 Jan 2008 20:30:32 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 48BD1E7ACB; Wed, 23 Jan 2008 17:30:30 -0800 (PST) Date: Thu, 24 Jan 2008 01:30:00 -0000 From: Joel Brobecker To: Pierre Muller Cc: 'Eli Zaretskii' , gdb-patches@sourceware.org Subject: Re: [RFA] Handle BINOP_INTDIV in valarith.c Message-ID: <20080124013030.GD3979@adacore.com> References: <002d01c85849$ef420f80$cdc62e80$@u-strasbg.fr> <002401c85c1a$b1997b30$14cc7190$@u-strasbg.fr> <20080123182514.GB3979@adacore.com> <001b01c85e10$48a8aa40$d9f9fec0$@u-strasbg.fr> <20080123230929.GC3979@adacore.com> <001d01c85e1b$5e280c70$1a782550$@u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001d01c85e1b$5e280c70$1a782550$@u-strasbg.fr> User-Agent: Mutt/1.4.2.2i 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/msg00574.txt.bz2 Pierre, You raised some valid points in your message. I got a code review for free :) and I sincerly thank you for that. I'll look into them as soon as I can. > OK, I get the idea, but the problem is that this leads to lots of code > copy... For this part, we can extract out the code you would otherwise duplicate and have the pascal_evaluate_subexp call it. > I agree with you that writing a pascal specific evaluate_subexp() > function is better that explicitly checking the language of the > currently parsed expression, but my idea was really to have on the > contrary something usable for other languages, and thus not inside > pascal specific code... I don't think that we'll have to give up on your suggestion to share the code. As explained above, any code that needs to be shared can be shared through a single function. Would it work? -- Joel