[PATCH] Must not modify the_index.cache as it may be passed to realloc at some point.

[Keith Packard <keithp@keithp.com>]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

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.
---
 builtin-ls-files.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 6c1db86..0028b8a 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -280,7 +280,7 @@ 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;
-- 
1.5.3.3.131.g34c6d-dirty

-- 
keith.packard@intel.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]