Re: 04: glib: g_list_free_1 should return ->next

[Owen Taylor <otaylor redhat com>]

Guido Draheim <guidod-2003- gmx de> writes:

> >>sure, me too. However, it's not made "depracated" either,
> >>while quite some other functionality is not marked as such
> >>and I can not see quite why. So this free_1 function is
> >>not to be replaced by delete_link for real, isn't it... ;-)
> > I don't really quite follow ... g_list_free_1() can be
> > used in places where delete_link() can't, since it makes
> > no assumptions as to how the node is linked.
> >
> 
> that's right - and in these places they walk up to the next
> item in the list - and that was the initial idea about this
> 04 note - to ask for api improvement that can make those places
> making use of free_1 simply a bit shorter and maintainable.

OK, then the answer is -- no reason to change g_[s]list_free_1
since we already have such an API.
 
> Where do you have g_list_free_1 that does not just be some
> synonym of g_list_free_head ? do you have some place on your
> mind when you phrased it as "used in places where delete_link
> can't" ? Perhaps that was written up in a hurry, since in
> effect the delete_link is just a combination of remove_link
> followed by freef_1 and it is hard to find a place where the
> reset of next/prev is inapropriate (minus implementation in
> glist.c where free_1 could live as a non-exported function)
>
> so far, it looks more as an optimization trick or some old
> code....

Most uses of g_[s]list_free_1() could indeed be
replaced with g_[s]list_delete_link(), now that exists.

If you want to make up a patch to do that, that would be
appreciated.

I don't see deprecating g_[s]list_free_1() though. 
 
 * It does do something distinct from g_[s]list_delete_link
 * We need it internally
 * Why make people rewrite code that works perfectly?

Regards,
                                        Owen