Yeah, that was totally bogus. It would re-allocate _part_ of an
allocation, but that allocation contained not just the index, but all the
hashes and the hash entries too!
This has nothing to do with moving a buffer - it has everything to do with
the fact that you shrunk a buffer that still contained all the other
buffers: you shrunk the "mem" allocation to fit just the first part of it,
and entirely ignored the "hash" and "entry" parts of it.
Btw, I think that whole "allocate everything in one allocation" thing is
potentially bogus even the way it is now, if the alignment constraints of
"index", "hash" and "entry" are different.
When you do
..
index = mem;
mem = index + 1;
hash = mem;
mem = hash + hsize;
entry = mem;
..
it's perfectly fine for "index", but "hash" and "entry" end up having
alignments that depend on the size/alignment of "index" (and for "entry"
on "hash").
So if their alignment requirements are different, you're basically
screwed.
It may work in practice (maybe they all align on pointer boundaries), but
it's damn scary. You should re-consider, or at least make that code be a
lot safer (like actually taking alignment into consideration, both for
total size and for the offset calculations).
That could be done by using unions or something.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
