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

[K. Piche]

On Mon, 2007-11-19 at 13:07 -0600, Dan McGee wrote:
> 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. :)

You could have a simple convention like GTK/GNOME stuff does: any
function arguments or returns that are "const" should not be freed by
the user (or front end in this case).  See "Cleanliness" in
http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html

k


> -Dan
> 
> _______________________________________________
> pacman-dev mailing list
> pacman-dev at archlinux.org
> http://archlinux.org/mailman/listinfo/pacman-dev
-- 
K. Piche <kpiche at rogers.com>