summaryrefslogtreecommitdiff
path: root/sha1_name.c
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2008-02-22 14:47:27 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2008-02-22 13:39:20 -0800
commit9ea0980a091b16501d143261eed40072030892e8 (patch)
tree11df624f30982c4d4948894eb18746757608725d /sha1_name.c
parentClarified the meaning of git-add -u in the documentation (diff)
downloadtgif-9ea0980a091b16501d143261eed40072030892e8.tar.xz
hash: fix lookup_hash semantics
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'sha1_name.c')
0 files changed, 0 insertions, 0 deletions