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

[Dan McGee]

On Dec 22, 2007 8:52 AM, Nagy Gabor <ngaba at bibl.u-szeged.hu> 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.
>
> Well, I don't know. alpm_list_remove is one of our most reliable
> functions, I cannot see any reason why it should fail (for example
> alpm_list_add is not so reliable, because it must allocate some memory
> for the new node header).
> So if I understood correctly, you want to indicate whether the
> to-be-removed element was found or not. I don't know if this is needed
> or not, because as I said above we can guarantee, that if the
> to-be-removed element exists, we remove it (one of them); and user
> probably wants to remove an existing element.
> But returning with your preferred integer doesn't hurt anything, so /me
> shrugs.

Um...I want to indicate *whether or not the operation was successful*.
That in turn does mean that we have removed an item from ignorepkg,
holdpkg, etc. That seems perfectly reasonable to me. I'm confused why
you would ever want to hid that information from an end user. If they
don't want it, just don't check it at all.

I couldn't give a crap whether a certain function is "reliable" or
whatever. That has NO bearing whatsoever on how another function
should work. And on Linux at least, unless you have set up your kernel
otherwise, a malloc call never fails.

-Dan