path: root/builtin-ls-files.c
diff options
authorKeith Packard <>2007-10-03 05:44:15 (GMT)
committerJunio C Hamano <>2007-10-03 06:18:58 (GMT)
commit95af39fcb2d84c8ef2844a9d890e3c67a2e0e1ec (patch)
treea75ca427b6832c01aded76499c4fb203a7619da5 /builtin-ls-files.c
parent96e24abc9f14c83abd1e269e1d5bc1c9e50d3fca (diff)
Must not modify the_index.cache as it may be passed to realloc at some point.
The index cache is not static, growing as new entries are added. If entries are added after prune_cache is called, cache will no longer point at the base of the allocation, and realloc will not be happy. I verified that this was the only place in the current source which modified any index_state.cache elements aside from the alloc/realloc calls in read-cache by changing the type of the element to 'struct cache_entry ** const cache' and recompiling. A more efficient patch would create a separate 'cache_base' value to track the allocation and then fix things up when reallocation was necessary, instead of the brute-force memmove used here. Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'builtin-ls-files.c')
1 files changed, 2 insertions, 1 deletions
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 6c1db86..171d449 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -280,7 +280,8 @@ static void prune_cache(const char *prefix)
if (pos < 0)
pos = -pos-1;
- active_cache += pos;
+ memmove(active_cache, active_cache + pos,
+ (active_nr - pos) * sizeof(struct cache_entry *));
active_nr -= pos;
first = 0;
last = active_nr;