1. 06 3月, 2008 1 次提交
  2. 05 3月, 2008 1 次提交
  3. 04 3月, 2008 4 次提交
  4. 03 3月, 2008 5 次提交
  5. 01 3月, 2008 3 次提交
  6. 29 2月, 2008 2 次提交
  7. 28 2月, 2008 10 次提交
  8. 27 2月, 2008 1 次提交
  9. 26 2月, 2008 6 次提交
  10. 25 2月, 2008 1 次提交
  11. 24 2月, 2008 4 次提交
  12. 23 2月, 2008 1 次提交
    • J
      hash: fix lookup_hash semantics · 9ea0980a
      Jeff King 提交于
      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: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9ea0980a
  13. 22 2月, 2008 1 次提交