From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15272 invoked by alias); 5 Sep 2003 16:29:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15263 invoked from network); 5 Sep 2003 16:29:10 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 5 Sep 2003 16:29:10 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 928372B7F; Fri, 5 Sep 2003 12:29:07 -0400 (EDT) Message-ID: <3F58B9D3.3020500@redhat.com> Date: Fri, 05 Sep 2003 16:29:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hilfinger Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Changes to allow extensions to operator set References: <20030901093941.0D2E9F2A64@nile.gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00074.txt.bz2 > 1. There was essentially duplicate code in prefixify_subexp and > length_of_subexp. I have factored out the duplication. [In the > process, by the way, I happened to notice that BINOP_VAL was > defined only in length_of_subexp, and indeed that there appears to > be no code anywhere to handle its evaluation.] If I understand it correctly, this refactoring (hey I get to use a buzword) making operator_length global and then calling it from length_of_subexp is independant of the other stuff, so yes, it can go in. Nice cleanup. Andrew