From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24008 invoked by alias); 23 Oct 2002 23:36:29 -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 23999 invoked from network); 23 Oct 2002 23:36:29 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 23 Oct 2002 23:36:29 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 184Vyl-0007gr-00 for ; Wed, 23 Oct 2002 19:36:03 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 184V3U-0001OH-00 for ; Wed, 23 Oct 2002 19:36:52 -0400 Date: Wed, 23 Oct 2002 16:36:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [patch] useless code in symtab.c Message-ID: <20021023233652.GA5247@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <15799.9088.601916.908293@localhost.redhat.com> <15799.10389.127424.360048@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-10/txt/msg00496.txt.bz2 On Wed, Oct 23, 2002 at 04:29:05PM -0700, David Carlton wrote: > On Wed, 23 Oct 2002 18:54:13 -0400, Elena Zannoni said: > > > David Carlton writes: > >> On Wed, 23 Oct 2002 18:32:32 -0400, Elena Zannoni said: > > >>> Can you also knock out the one at: > > >>> linespec.c:38:extern char *find_template_name_end (char *); > > >> That one gets used by decode_line_1. (One of these days, I'll try > >> to understand what that function is doing, but I'm not feeling > >> quite that masochistic yet.) Though I don't see any compelling > >> reason not to just #include "parser-defs.h" there instead of > >> declaring that one function specially; should I go ahead and do > >> that? > > > decode_line_1, I think it will also make coffee if you ask > > nicely.... :-( > > I really will have to give it a look; refactoring lookup_symbol_aux > was fairly pleasant and has turned out to be quite useful for me, so > at some point I'll see if decode_line_1 is amenable to a similar > treament. Probably not, though: lookup_symbol_aux breaks fairly > neatly into a few decent-sized chunks, whereas decode_line_1 is a good > deal longer (770 lines as opposed to 370) and seems to me, upon a > brief skim, to not want to break apart nearly as nicely. I admit (blasphemy!) I'm strongly considering declaring it dead, and rewriting it to meet a proper specification. This means coming up with one first though, so it's a little bit down my list. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer