From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31464 invoked by alias); 7 Jan 2003 22:22:54 -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 31445 invoked from network); 7 Jan 2003 22:22:52 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 209.249.29.67 with SMTP; 7 Jan 2003 22:22:52 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h07MMeE10314; Tue, 7 Jan 2003 14:22:40 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: gdb Cc: Elena Zannoni , Jim Blandy , Fernando Nasser Subject: [rfc] plans for linespec.c From: David Carlton Date: Tue, 07 Jan 2003 22:22:00 -0000 Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-01/txt/msg00064.txt.bz2 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. * 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. * 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. 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. 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? David Carlton carlton@math.stanford.edu