Re: [PATCH v3 2/2] read-cache: plug a few leaks

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Jun 8, 2013, 16:53 UTC
Message-ID: <CAMP44s3UYCX+DzgnErB=0GdD3w5k2GkNKjv46ZA_NVHm1Z0YLQ@mail.gmail.com>
In-Reply-To: <51B35414.1090101@lsrfire.ath.cx>

On Sat, Jun 8, 2013 at 10:56 AM, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:

Show 22 quoted lines

> Am 08.06.2013 16:04, schrieb Felipe Contreras:
>
>> On Sat, Jun 8, 2013 at 8:22 AM, René Scharfe
>> <rene.scharfe@lsrfire.ath.cx> wrote:
>>>
>>> Am 08.06.2013 14:15, schrieb Felipe Contreras:
>>
>>
>>>> Why leave it out? If somebody makes the mistake of doing the above
>>>> sequence, would you prefer that we leak?
>>>
>>>
>>> Leaking is better than silently cleaning up after a buggy caller because
>>> it
>>> still allows the underlying bug to be found.
>>
>>
>> No, it doesn't. The pointer is replaced and forever lost. How is
>> leaking memory helping anyone to find the bug?
>
> Valgrind can tell you where leaked memory was allocated, but not if you free
> it in the "wrong" place.

It is the correct place to free it. And nobody will ever find it with valgrind, just like nobody has ever tracked down the hundreds of leaks in Git that happen reliably 100% of the time, much less the ones that happen rarely.

-- 
Felipe Contreras