From: David Carlton <carlton@math.stanford.edu>
To: Elena Zannoni <ezannoni@redhat.com>
Cc: gdb-patches@sources.redhat.com, Jim Blandy <jimb@redhat.com>
Subject: Re: [patch] useless code in symtab.c
Date: Wed, 23 Oct 2002 16:29:00 -0000 [thread overview]
Message-ID: <ro1k7k83fb2.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <15799.10389.127424.360048@localhost.redhat.com>
On Wed, 23 Oct 2002 18:54:13 -0400, Elena Zannoni <ezannoni@redhat.com> said:
> David Carlton writes:
>> On Wed, 23 Oct 2002 18:32:32 -0400, Elena Zannoni <ezannoni@redhat.com> 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.
Incidentally, have you looked over the lookup_symbol_aux refactoring
yet? (At
<http://sources.redhat.com/ml/gdb-patches/2002-10/msg00080.html>.)
It's not particularly urgent yet, but at some point I'm going to need
to need to get some sort of consensus as to what it means to look
something up in the global symbol table, and that patch is a good
starting place for discussion. I think it's all a good idea except
maybe I shouldn't move the partial symbol table lookup before the
minimal symbol table lookup just yet.
> Yes, please, and update the Makefile.in dependencies.
Great, will do.
David Carlton
carlton@math.stanford.edu
next prev parent reply other threads:[~2002-10-23 23:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-23 15:27 David Carlton
2002-10-23 15:35 ` Elena Zannoni
2002-10-23 15:43 ` David Carlton
2002-10-23 15:57 ` Elena Zannoni
2002-10-23 16:29 ` David Carlton [this message]
2002-10-23 16:36 ` Daniel Jacobowitz
2002-10-23 17:20 ` Elena Zannoni
2002-10-23 17:25 ` David Carlton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ro1k7k83fb2.fsf@jackfruit.Stanford.EDU \
--to=carlton@math.stanford.edu \
--cc=ezannoni@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox