From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24126 invoked by alias); 8 Jan 2003 14:25:38 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 24104 invoked from network); 8 Jan 2003 14:25:37 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 8 Jan 2003 14:25:37 -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 h08DvhB00616 for ; Wed, 8 Jan 2003 08:57:43 -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 h08EPPa13407; Wed, 8 Jan 2003 09:25:25 -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 h08EPNn11861; Wed, 8 Jan 2003 09:25:23 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id D60C4FF79; Wed, 8 Jan 2003 09:29:46 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15900.13786.731656.596183@localhost.redhat.com> Date: Wed, 08 Jan 2003 14:25:00 -0000 To: David Carlton Cc: gdb , Elena Zannoni , Jim Blandy , Fernando Nasser Subject: Re: [rfc] plans for linespec.c In-Reply-To: References: X-SW-Source: 2003-01/txt/msg00078.txt.bz2 David Carlton writes: > I've just submitted the last of a series of patches to linespec.c that > begin cleaning up the function decode_line_1. So now it's 160 lines > long instead of 780 lines long, or whatever it was before. (Of > course, the extra lines haven't gone away, they've just moved into > their own functions.) > > It still has a long way to go; right now, there are a few different > ways in which progress can be made. > > * The C++ stuff should be broken up into smaller functions, just like > I did with decode_line_1. It's already divided up into multiple > functions, but some of them are still too large. > It's a first step, and eventually can be moved to a separate file. > * decode_line_1 should be cleaned up still further. My goal is to > have it eventually look as follows: > > decode_line_1 () > { > /* Some functions to initialize all the various flags and > variables. */ > > /* Several blocks of the following form, for different values of > XXX. */ > > if (is_XXX ()) > return decode_XXX () > } > > So, basically, some of the predicates have to get simpler, and some > of the initialization code (set_flags, symtab_from_filename) should > move earlier in the function. > Sounds sane. > * Trivial fixes for clarity/ARI: make sure comments end in a period > and two spaces, rename variables so that their name reflects their > use, define the functions in a consistent order, etc. > yep. > These three are all logically independent of each other. I think > Elena suggested that the trivial fixes could be handled as obvious > patches once decode_line_1 had gotten simplified a bit; it seems to me > that now is an appropriate time to start on that. And I think I'd > rather do the C++ stuff before cleaning up decode_line_1: the logic > behind those patches is simpler, and I've finished that in my own > private copy of the file whereas I haven't finished all of the further > decode_line_1 cleanup in my private copy. > > So what makes sense for me to do is: > > 1) Start doing some obvious patches that only do stuff like change > formatting, rename variables, etc.; unless Elena or somebody else > objects, I'll post these to gdb-patches but I won't wait for > approval, since they clearly won't change GDB's behavior. > This is ok, as long as the patches are simple. I.e. better have more smaller patches, rather than a big one. But you know this already! > 2) Start submitting a series of patches to break up decode_compound > and functions that it calls into smaller functions, just like I've > been doing with decode_line_1. These will, of course, require > approval. > > Once all that's done, I'll then get back to cleaning up decode_line_1 > some more. > > How does that sound? > Sounds good. Elena > David Carlton > carlton@math.stanford.edu