From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27359 invoked by alias); 7 Nov 2002 17:34:45 -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 27178 invoked from network); 7 Nov 2002 17:34:42 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 Nov 2002 17:34:42 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gA7HBvw17496 for ; Thu, 7 Nov 2002 12:11:57 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA7HYcf30978; Thu, 7 Nov 2002 12:34:38 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA7HYaT25054; Thu, 7 Nov 2002 12:34:36 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id 8482DFF79; Thu, 7 Nov 2002 12:30:26 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15818.41778.383411.897868@localhost.redhat.com> Date: Thu, 07 Nov 2002 09:34:00 -0000 To: David Carlton Cc: gdb-patches@sources.redhat.com, Jim Blandy , Elena Zannoni , Fernando Nasser Subject: Re: [rfc] clean up linespec.c In-Reply-To: References: X-SW-Source: 2002-11/txt/msg00177.txt.bz2 David Carlton writes: > For various reasons, I've been cleaning up linespec.c on a branch; I > find the resulting version of linespec.c enough more > legible/maintainable that I suspect I'm not the only person who would > find it useful. > You bet! > The cleanups consist almost entirely of refactoring rather than > changing the behavior: I've broken up large functions into multiple > small functions, renamed variable names to make their use clearer, and > the like. Since I was already touching so much of the code, I also > fixed up stylistic niceties: using NULL where appropriate, deleting > unnecessary casts, fixing comments to end in a period followed by two > spaces, and stuff like that. > cool > It turns out that decode_line_1 isn't quite as crazy a function as I'd > feared. There's a reasonable flow of control underneath (well, at > least there is once you get rid of the unnecessary goto's), though > admittedly the C++ part of the function is still pretty complicated, > and the function will always consist of a bunch of special cases. > Having c++ separated in functions, is a first step in moving C++ support to its own files.....:-) > I hope I didn't break anything, though my only real evidence for that > is that I didn't get any new regressions on the testsuite. (I have no > idea how comprehensive the testsuite's coverage of linespec is.) ah, gcov data would be useful here... :-) > > So: should I submit an RFA? Or, more likely, should I start > submitting a bunch of RFA's, one at a time? I suspect it will take a > double-digit number of RFA's to break up the changes into manageable > chunks, though if you get sick of reading them, you can always approve > the changes all at once. :-) > Yes a bunch of rfa's in rapid succession is the way to go. I've looked at your version below, and it looks like the patches would be fairly obvious. I'd reccommend that the other fixes, like reformatting, adding spaces after periods, etc. could be done after the code movement patches (or before, whatever is less work for you), as a single patch that spans the whole file. That would just be obvious. > I'm enclosing a copy of my current version of the code after my > signature, so you can see what I have to offer. I won't write up a > ChangeLog for the whole thing at once, just ones for each RFA; if I > were to write one for the whole thing at once, it would consist almost > exclusively of entries like these: > > (existing function): Move chunks of code into separate functions; > clean up. > (new function): New function. > > David Carlton > carlton@math.stanford.edu > Elena