[pacman-dev] [PATCH] Add remove counterparts to alpm_option_add_* functions

[Allan McRae]

Dan McGee wrote:
> Quick first thought here is these functions should not be void return
> type, but int so they can return whether they were successful or not.
> Of course, that provokes a second thought that notices that the list
> remove function has a rather odd function signature.
>
> It looks like you could pass in a data pointer (set your vdata ptr to
> null first to be safe), and check after the remove call if something
> is in this pointer. If there was something, you actually have to free
> it (because of memory leak issues, which I just realized would
> happen). Finally, return true (1) if there was data returned, and
> false (0) if data was not found.
>
> Thoughts from anyone else also welcome.
>
> -Dan
OK.  That is easy enough to do.  I followed the only other uses of 
alpm_list_remove (in libalpm/{cache,db}.c).  It looks like there is a 
leak in db.c with the "data" variable not being cleared.  In cache.c, 
"vdata" gets freed in _alpm_db_remove_pkgfromcache as it is assigned to 
"data" which is freed.  I don't get why "data" is not used in 
alpm_list_remove in the first place - there could be something about C I 
am missing there as I only really know C++.  Anyway, I can tidy these up 
tomorrow.

Allan