From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Sun, 09 Jun 2013 02:11:24 GMT
Subject: Re: [PATCH v3 2/2] read-cache: plug a few leaks
Message-ID: <51B3E44C.4030304@lsrfire.ath.cx>
In-Reply-To: <CAMP44s1ffOUd3DkphHAj8ZmovBazPFdMgtvEptR6kW9+ZMLLjA@mail.gmail.com>

Am 08.06.2013 19:27, schrieb Felipe Contreras:
> On Sat, Jun 8, 2013 at 12:22 PM, René Scharfe
> <rene.scharfe@lsrfire.ath.cx> wrote:
>
>> Let's find and fix those leaks by freeing memory in the right places.
>> Freeing memory just in case in places where we can show that no leak is
>> triggered by our test suite doesn't help.
>
> It helps; it prevents leaks. The real culprit is the bogus API, but I
> don't see that changing anytime soon, so there are two options when
> somebody makes a mistake the API allows; leak or don't leak. And you
> seem to prefer the leak, even though it provides absolutely no
> advantage.

It covers up bugs, which may seem helpful, but isn't, because it's 
better to fix the actual mistake.

What would be a better API?  Making discard_index free the array is a 
good first step; what else is bogus?

René