Skip to content
  • Jeff King's avatar
    hash: fix lookup_hash semantics · 9ea0980a
    Jeff King authored and Junio C Hamano's avatar Junio C Hamano committed
    
    
    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: default avatarJeff King <peff@peff.net>
    Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    9ea0980a