Thread (12 messages) flat view 12 messages, 3 authors, 2016-06-15

Re: [PATCH 7/7] unpack-trees: free cache_entry array members for merges

From: Felipe Contreras <hidden>
Date: 2016-06-15 22:57:30

On Thu, May 30, 2013 at 9:40 AM, René Scharfe
[off-list ref] wrote:
Am 30.05.2013 14:04, schrieb Felipe Contreras:
quoted
On Thu, May 30, 2013 at 6:34 AM, René Scharfe
[off-list ref] wrote:
quoted
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..
quoted
@@ -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?
Both. In particular I'm eyeballing the code you can even see in this patch:

 src[i + o->merge] = create_ce_entry(info, names + i, stage);

If you think it's better to use src[i], then I think the code above
should do the same.

-- 
Felipe Contreras
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help