On Nov 19, 2007 12:43 PM, Nagy Gabor <ngaba@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