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. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

On Mon, 2007-11-19 at 13:07 -0600, Dan McGee wrote:

On Nov 19, 2007 12:43 PM, Nagy Gabor 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@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev -- K. Piche

On Mon, Nov 19, 2007 at 10:45:53PM -0500, "K. Piche" wrote:

...

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

or just use __attribute__ ((__warn_unused_result__)) on those functions. obviously those functions' return value must be free'd. - VMiklos