From: Jason Molenda <jason-swarelist@molenda.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] bug in symtab.c:lookup_block_symbol()'s search method
Date: Sat, 15 Sep 2001 12:52:00 -0000 [thread overview]
Message-ID: <20010915125120.A11429@shell17.ba.best.com> (raw)
In-Reply-To: <2110-Sat15Sep2001133818+0300-eliz@is.elta.co.il>
On Sat, Sep 15, 2001 at 01:38:18PM +0300, Eli Zaretskii wrote:
> > Dan's patch dropped the "exits out of linear search" -- now it
> > binary searches to the beginning of plausible ranges, and steps
> > through to the end of the block. It's now an O(1/2*N) algorithm
> > for worst-case, i.e. non-matches.
>
> Are you saying that Dan's change was a gratuitous one, i.e. there was
> no reason whatsoever to make that change?
Yes. The lookup_block_symbol() function already depends on the
first character being a meaningful, comparable character (the binary
search is based on this, and on strcmp() of all things), so ending
the search based on this criteria will not further weaken this
algorithm.
If there is real concern that this method of comparison is invalid
for some languages, then the entire patch Dan submitted needs to
be reworked or we need to stick with comparing only mangled/native
names.
It can't be had both ways -- either the whole conversion to umangled
comparisons, as it is currently written, is invalid, or my correction
of the linear search is correct. The current lookup_block_symbol
search code is as incorrect as my patch. The only benefits of the
current lookup_block_symbol code is that it linear searches over half
of the symbols in the block, so it stands a 50% chance of hitting one
of these names that we're talking about. I'd not characterize that
as 'correct'.
Jason
next prev parent reply other threads:[~2001-09-15 12:52 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-09 7:48 Jason Molenda
2001-09-10 11:24 ` Michael Snyder
2001-09-10 11:32 ` Jason Molenda
2001-09-10 11:50 ` Daniel Berlin
2001-09-10 11:52 ` Daniel Berlin
[not found] ` <20010910130347.A5628@shell17.ba.best.com>
2001-09-10 14:17 ` Daniel Berlin
2001-09-14 7:53 ` Andrew Cagney
2001-09-14 8:53 ` Daniel Berlin
2001-09-14 9:06 ` Eli Zaretskii
2001-09-14 9:13 ` Jason Molenda
2001-09-14 9:58 ` Daniel Berlin
2001-09-14 10:55 ` Eli Zaretskii
2001-09-14 10:52 ` Eli Zaretskii
2001-09-14 10:59 ` Daniel Jacobowitz
2001-09-14 11:57 ` Eli Zaretskii
2001-09-15 0:54 ` Jason Molenda
2001-09-15 3:43 ` Eli Zaretskii
2001-09-15 8:01 ` Daniel Berlin
2001-09-15 9:09 ` Eli Zaretskii
2001-09-15 12:36 ` Daniel Jacobowitz
2001-09-15 12:52 ` Jason Molenda [this message]
2001-09-15 7:54 ` Daniel Berlin
2001-09-15 13:08 ` Jason Molenda
2001-09-15 13:33 ` Daniel Berlin
2001-09-15 13:52 ` Daniel Berlin
2001-09-15 14:02 ` Jason Molenda
2001-09-15 14:21 ` Daniel Berlin
2001-09-16 0:15 ` Eli Zaretskii
2001-09-17 22:56 ` Andrew Cagney
2001-09-17 23:12 ` Jason Molenda
2001-09-18 6:21 ` Daniel Berlin
2001-09-18 7:32 ` Andrew Cagney
2001-09-17 23:18 ` Daniel Jacobowitz
2001-09-18 4:51 ` Eli Zaretskii
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=20010915125120.A11429@shell17.ba.best.com \
--to=jason-swarelist@molenda.com \
--cc=eliz@is.elta.co.il \
--cc=gdb-patches@sources.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