Our hash_obj and hashtable_index calls and functions were doing a lot of
funny things with signedness. Unify all of it to 'unsigned int'.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In these two places we are casting part of our unsigned char sha1 array into
an unsigned int, which violates GCCs strict-aliasing rules (and probably
other compilers).
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We don't actually modify the struct object, so there is no
reason not to accept const versions (and this allows other
callsites, like the next patch, to use the decoration
machinery).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The export_marks() function iterated over a (potentially sparsely
populated) hashtable, but it accessed it starting from offset 1 and one
element beyond the end.
Noticed by SungHyun Nam.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Duh.
When I did the object decorator thing, I made the "loop over the hash"
function use the same logic for updating the hash, ie made them use
if (++j >= size)
j = 0;
for both the hash update for both "insert" and "lookup"
HOWEVER.
For some inexplicable reason I had an extraneous
j++;
in the insert path (probably just from the fact that the old code there
used
j++;
if (j >= size)
j = 0;
and when I made them use the same logic I just didn't remove the old
extraneous line properly.
This fixes it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows you to add an arbitrary "decoration" of your choice to any
object. It's a space- and time-efficient way to add information to
arbitrary objects, especially if most objects probably do not have the
decoration.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
