threads / patch / 12261

patchhash: fix lookup_hash semantics

Subject: [PATCH] hash: fix lookup_hash semantics

## tl;dr

4 messages between Feb 22, 2008 and Feb 22, 2008. Diffs are folded; open one to read it.

replies: 3people: 4as markdown or json

Jeff King· Feb 22, 2008, 19:47 UTC · lore

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(-)
Show changes to hash.c +1 −1
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
Linus Torvalds· Feb 22, 2008, 20:42 UTC · re: Jeff King · lore

Re: [PATCH] hash: fix lookup_hash semantics

On Fri, 22 Feb 2008, Jeff King wrote:
Show 5 quoted lines
>
> 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.

Gaah. That code returned the pointer-to-a-pointer exactly because of the insert case, but then to clean it up I had split it up into that internal "lookup_hash_entry()" case, but left the broken semantics for lookup_hash().

Stupid.

Your patch is obviously correct, and should probably go into maint just so that no other code makes the mistake of using that broken interface.

		Linus
Junio C Hamano· Feb 22, 2008, 20:54 UTC · re: Jeff King · lore

Re: [PATCH] hash: fix lookup_hash semantics

Jeff King <peff@peff.net> writes:
> 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.
Very nicely spotted.  Thanks.
Pieter de Bie· Feb 22, 2008, 22:13 UTC · re: Jeff King · lore

Re: [PATCH] hash: fix lookup_hash semantics

On Feb 22, 2008, at 8:47 PM, Jeff King wrote:
> 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.

I think my original message may not have come through as it was in HTML accidentally.

Anyway, I tested the patch and it works. Thanks!
Tested-by: Pieter de Bie <pdebie@ai.rug.nl>
- Pieter

← back to recent threads