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

From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: May 30, 2013, 14:40 UTC
Message-ID: <51A764CE.4000708@lsrfire.ath.cx>
In-Reply-To: <CAMP44s2=YuBLHgz52ie-FZYU5iz4o4tY0-zH+6XuzpiupjomLA@mail.gmail.com>

Am 30.05.2013 14:04, schrieb Felipe Contreras:

Show 23 quoted lines

> On Thu, May 30, 2013 at 6:34 AM, René Scharfe
> <rene.scharfe@lsrfire.ath.cx> 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é