On Mon, Jun 3, 2013 at 12:40 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> I don't see that, and I don't like adding a check that I don't expect to be
>>> ever needed.
>>
>> It's called self-documenting code; by adding a check for the NULL
>> pointer, we are stating that ce can be NU
Felipe Contreras writes:
>> I don't see that, and I don't like adding a check that I don't expect to be
>> ever needed.
>
> It's called self-documenting code; by adding a check for the NULL
> pointer, we are stating that ce can be NULL, if we don't do that,
> people reading that code would need t
On Mon, Jun 3, 2013 at 10:59 AM, René Scharfe
wrote:
> Am 03.06.2013 02:04, schrieb Felipe Contreras:
>>
>> On Sun, Jun 2, 2013 at 6:47 PM, René Scharfe
>> wrote:
>>>
>>> Am 03.06.2013 01:23, schrieb Felipe Contreras:
>>>
I didn't say we should do 'if (ce) free(ce);' instead of 'free(ce);' I
Am 03.06.2013 02:04, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 6:47 PM, René Scharfe
wrote:
Am 03.06.2013 01:23, schrieb Felipe Contreras:
I didn't say we should do 'if (ce) free(ce);' instead of 'free(ce);' I
said we should do 'if (cd && ce != o->df_conflict_entry)' instead of
'if (ce
On Sun, Jun 2, 2013 at 6:47 PM, René Scharfe
wrote:
> Am 03.06.2013 01:23, schrieb Felipe Contreras:
>
>> I didn't say we should do 'if (ce) free(ce);' instead of 'free(ce);' I
>> said we should do 'if (cd && ce != o->df_conflict_entry)' instead of
>> 'if (ce != o->df_conflict_entry)'.
>
>
> I did
Am 03.06.2013 01:23, schrieb Felipe Contreras:
I didn't say we should do 'if (ce) free(ce);' instead of 'free(ce);' I
said we should do 'if (cd && ce != o->df_conflict_entry)' instead of
'if (ce != o->df_conflict_entry)'.
I did assume you meant the latter.
There's no reason not to.
Only the
On Sun, Jun 2, 2013 at 6:06 PM, René Scharfe
wrote:
> Am 03.06.2013 00:38, schrieb Felipe Contreras:
>
>> On Sun, Jun 2, 2013 at 3:26 PM, René Scharfe
>> wrote:
>>>
>>> Am 02.06.2013 19:59, schrieb Felipe Contreras:
>>>
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
wrote:
>
>
>
Am 03.06.2013 00:38, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 3:26 PM, René Scharfe
wrote:
Am 02.06.2013 19:59, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
wrote:
Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM, René Sch
On Sun, Jun 2, 2013 at 3:26 PM, René Scharfe
wrote:
> Am 02.06.2013 19:59, schrieb Felipe Contreras:
>
>> On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
>> wrote:
>>>
>>> Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
wrote:
>
Am 02.06.2013 19:59, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
wrote:
Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
wrote:
+ for (i = 0; i < n; i++) {
+ struct cache_entry *ce =
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
wrote:
> Am 02.06.2013 19:25, schrieb Felipe Contreras:
>>
>> On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
>> wrote:
>>>
>>> + for (i = 0; i < n; i++) {
>>> + struct cache_entry *ce = src[i + o->merge];
>>> +
Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
wrote:
+ for (i = 0; i < n; i++) {
+ struct cache_entry *ce = src[i + o->merge];
+ if (ce != o->df_conflict_entry)
It's possible that ce is NU
On Sun, Jun 2, 2013 at 10:46 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.
>
> As suggested by Felipe, use the same loop style (zero-base
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.
As suggested by Felipe, use the same loop style (zero-based for loop)
for freeing as for allocating.
Improved-by: Felipe
14 matches
Mail list logo
