From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
git@vger.kernel.org, Dane Jensen <careo@fastmail.fm>,
Pieter de Bie <pdebie@ai.rug.nl>
Subject: [PATCH] hash: fix lookup_hash semantics
Date: Fri, 22 Feb 2008 14:47:27 -0500 [thread overview]
Message-ID: <20080222194726.GA24532@sigill.intra.peff.net> (raw)
We were returning the _address of_ the stored item (or NULL)
instead of the item itself. While this sort of indirection
is useful for insertion (since you can lookup and then
modify), it is unnecessary for read-only lookup. Since the
hash code splits these functions between the internal
lookup_hash_entry function and the public lookup_hash
function, it makes sense for the latter to provide what
users of the library expect.
The result of this was that the index caching returned bogus
results on lookup. We unfortunately didn't catch this
because we were returning a "struct cache_entry **" as a
"void *", and accidentally assigning it to a "struct
cache_entry *".
As it happens, this actually _worked_ most of the time,
because the entries were defined as:
struct cache_entry {
struct cache_entry *next;
...
};
meaning that interpreting a "struct cache_entry **" as a
"struct cache_entry *" would yield an entry where all fields
were totally bogus _except_ for the next pointer, which
pointed to the actual cache entry. When walking the list, we
would look at the bogus "name" field, which was unlikely to
match our lookup, and then proceed to the "real" entry.
The reading of bogus data was silently ignored most of the
time, but could cause a segfault for some data (which seems
to be more common on OS X).
Signed-off-by: Jeff King <peff@peff.net>
---
This can be applied to maint, but there aren't actually any
callers of lookup_hash until Linus' recent patch series, so it really
only makes sense on top of that. Alternatively, his patches could be
altered to dereference the return from lookup_hash, but I think this
calling convention makes more sense (for the reasons I explained above).
This shuts up the valgrind errors I see under Linux; it would be nice to
get confirmation from OS X people that this fixes their "git status"
segfaults.
hash.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hash.c b/hash.c
index 7b492d4..d9ec82f 100644
--- a/hash.c
+++ b/hash.c
@@ -70,7 +70,7 @@ void *lookup_hash(unsigned int hash, struct hash_table *table)
{
if (!table->array)
return NULL;
- return &lookup_hash_entry(hash, table)->ptr;
+ return lookup_hash_entry(hash, table)->ptr;
}
void **insert_hash(unsigned int hash, void *ptr, struct hash_table *table)
--
1.5.4.2.262.g044a1.dirty
next reply other threads:[~2008-02-22 19:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-22 19:47 Jeff King [this message]
2008-02-22 20:42 ` [PATCH] hash: fix lookup_hash semantics Linus Torvalds
2008-02-22 20:54 ` Junio C Hamano
2008-02-22 22:13 ` Pieter de Bie
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=20080222194726.GA24532@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=careo@fastmail.fm \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pdebie@ai.rug.nl \
--cc=torvalds@linux-foundation.org \
/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;
as well as URLs for NNTP newsgroup(s).