[pacman-dev] [PATCH 1/5] Two memleak fixes in pacman.

[Dan McGee]

On Nov 19, 2007 12:43 PM, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
> > Obviously I'll apply this. However, from a design standpoint, I really
> > wish we never had to call alpm_list_free() from the frontend on
> > anything returned by the library. When we start having to do that, it
> > leads to double frees and all sorts of other fun stuff.
>
> I simply don't understand this. All known libraries _must_ use this when they
> _compute_ something on request. The library simply doesn't know if the result is
> still needed by the caller (front-end) or not. You may say we could implement
> whatprovides_ready, but this is just equivalent with list_free (and ugly).
> The main problem here, that we have no libalpm documentation where we could
> define for front-ends which results should be freed and which should not.

And that is my point. We don't have a clear definition of what needs
freeing and what does not. The name "alpm_db_whatprovides" doesn't
indicate at all that its result needs to be freed, and yet something
like "alpm_fetch_pkgurl" doesn't need freeing (or does it? I don't
know and that seems problematic).

So yes, it comes down to documentation and good function naming, which
we lack. :)

-Dan