Re: [PATCH v3 2/2] read-cache: plug a few leaks
- From
René Scharfe <rene.scharfe@lsrfire.ath.cx>
- Date
- Jun 9, 2013, 02:11 UTC
- Message-ID
- <51B3E44C.4030304@lsrfire.ath.cx>
- In-Reply-To
- <CAMP44s1ffOUd3DkphHAj8ZmovBazPFdMgtvEptR6kW9+ZMLLjA@mail.gmail.com>
Am 08.06.2013 19:27, schrieb Felipe Contreras:
Show 12 quoted lines
> 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é