Re: [pacman-dev] [PATCH] Fix memleaks in front-end caused by dynamic memory allocation

2008-10-24 Thread Nagy Gabor

On Fri, Oct 24, 2008 at 12:00 PM, Nagy Gabor [EMAIL PROTECTED] 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/


___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev


Re: [pacman-dev] [PATCH] Fix memleaks in front-end caused by dynamic memory allocation

2008-10-24 Thread Aaron Griffin
On Fri, Oct 24, 2008 at 4:03 PM, Dan McGee [EMAIL PROTECTED] 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.
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev