[pacman-dev] [PATCH] Fix memleaks in front-end caused by dynamic memory allocation
http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working I know you may not like this way (free functions public), but IMHO the result is not so ugly ;-) Off-topic: A small thing. During working on this patch I realized, that "\nerrors occurred, no packages were upgraded.\n" message is printed after -U fileconflict error only. Is this intentional? (Anyway, IMHO that message is useless.) Bye ------------------------------------------------------ SZTE Egyetemi Konyvtar - http://www.bibl.u-szeged.hu This message was sent using IMP: http://horde.org/imp/
On Fri, Oct 24, 2008 at 12:00 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
I know you may not like this way (free functions public), but IMHO the result is not so ugly ;-)
Can we just expose something more like "free_conflictlist"? Having those casts and stuff is rather ugly on the public side of the library usage.
Off-topic: A small thing. During working on this patch I realized, that "\nerrors occurred, no packages were upgraded.\n" message is printed after -U fileconflict error only. Is this intentional? (Anyway, IMHO that message is useless.)
Bye
------------------------------------------------------ SZTE Egyetemi Konyvtar - http://www.bibl.u-szeged.hu This message was sent using IMP: http://horde.org/imp/
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
On Fri, Oct 24, 2008 at 12:00 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
I know you may not like this way (free functions public), but IMHO the result is not so ugly ;-)
Can we just expose something more like "free_conflictlist"? Having those casts and stuff is rather ugly on the public side of the library usage.
When we walk through the data list in the front-end, we could do alpm_*_free(i->data) inside the loop. This may looks better, but I don't think it is nicer. (But at least we don't need casts.) I may give a try to implement specific list-free functions, but there is one more thing which is not nice here. Namely, the free(list) function depends on the error type, which is also ugly imho. Maybe we should pass somehow a free function somehow with data list as well, or somehow do the free task in back-end (how?). Irl, these *data lists are not used. I mean, it is used for printing error messages only. Obviously the back-end could build these messages and print via alpm_log(PM_LOG_ERROR,...) I guess this data list was designed to give the ability of "handling" these errors to the front-end (a front-end after some user interaction could resolve deps?). If this "flexibility" is not important, we could simply drop these (ugly) data lists. Bye PS: Dan, sorry about my previous direct mail. ------------------------------------------------------ SZTE Egyetemi Konyvtar - http://www.bibl.u-szeged.hu This message was sent using IMP: http://horde.org/imp/
On Fri, Oct 24, 2008 at 4:03 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Can we just expose something more like "free_conflictlist"? Having those casts and stuff is rather ugly on the public side of the library usage.
I was always a fan of the libraries that did something of the sort: struct list_node { void *data; struct list_node *next; void (*free_func)(void *); }; ... void free_list_node(struct list_node *node) { if(node->free_func && node->data) { node->free_func(node->data); free(node); } } And free_func is set when a node is added. Alternatively: struct list_node { void *data; struct list_node *next; } struct list_head { struct list_node *head; void (*free_func)(void *); } ... void free_list(struct list_head *l) { void (*fn)(void *) = l->free_func; for(struct list_node i = l->head; i;) { if(fn && i->data) fn(i->data); struct list_node *tmp = i->next; free(i); i = tmp; } } I know it's a lot of work, but it's far cleaner than exposing node freeing functions to the front ends.
participants (3)
-
Aaron Griffin
-
Dan McGee
-
Nagy Gabor