From: René Scharfe Date: Thu, 30 May 2013 14:40:14 GMT Subject: Re: [PATCH 7/7] unpack-trees: free cache_entry array members for merges Message-ID: <51A764CE.4000708@lsrfire.ath.cx> In-Reply-To: Am 30.05.2013 14:04, schrieb Felipe Contreras: > On Thu, May 30, 2013 at 6:34 AM, René Scharfe > wrote: >> The merge functions duplicate entries as needed and they don't free >> them. Release them in unpack_nondirectories, the same function >> where they were allocated, after we're done. > > Ah, you beat me to this change, but.. > >> @@ -600,9 +600,14 @@ static int unpack_nondirectories(int n, unsigned long mask, >> src[i + o->merge] = create_ce_entry(info, names + i, stage); >> } >> >> - if (o->merge) >> - return call_unpack_fn((const struct cache_entry * const *)src, >> - o); >> + if (o->merge) { >> + int rc = call_unpack_fn((const struct cache_entry * const *)src, >> + o); >> + for (i = 1; i <= n; i++) >> + if (src[i] && src[i] != o->df_conflict_entry) >> + free(src[i]); > > Doesn't it make more sense to follow the code above and do src[i + o->merge]? Not sure I understand. Is the goal to avoid confusion for code readers by using the same indexing method for allocation and release? Or are you worried about o->merge having a different value than 1 in that loop? We'd have to add 1 (== o->merge) to each index variable usage with a zero-based loop. A one-based loop avoids that, and while it's not pretty it's also not too complicated, I think. René