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

[Guido Draheim <guidod-2003- gmx de>]

Owen Taylor wrote:
> > > > > I don't think this change makes sense though:
> > > > > A) g_list_free_1() doesn't unlink the list node either,
> > > > >   so just returning next doesn't do any good.     g_list_free_1()
> > > > > simply frees a single list node
> > > > >   that is already unlinked.
> > > > > B) g_list_delete_link is exactly what you are looking for.
> > > >
> > > > in other words,
> > > > list = g_list_delete_link (list, list);
> > > >
> > > > looking through the fifteen places where g_list_free_1 is
> > > > currently used, that would be also true about there - so that
> > > > the free_1 would have to be depracated. It is not done since
> > > > it is known about there that we are the head and no unlink
> > > > operation is actually needed since it is intended to just
> > > > walk-and-free the list. It is actually a common task to do,
> > > > to have a "select" routine to return an allocated glist and
> > > > have the receiver walk-and-free the result-set.
> > >
> > > g_list_free_1 is a perfectly legitimate operation, it't
> > > just not what you are looking for. It's basically the
> > > opposite of g_list_alloc().
> > > The reason we added g_list_delete_link() (a GLib-2.0 addition)
> > > was because the operation of deleting the head node off of a list
> > > was a common one. The code you are looking at was
> > > probably written before then.
> >
> > aaaaahhh!!!!!
> >
> > however, some of these places are in glib2 itself - and given
> > the lack of programming examples, they are taken as a guideline.
> >
> > furthermore, the g_list_delete_link algorithm is a bit bloated
> > for the operation of g_list_delete_head - the case that checks
> > for (list == link) is a bit late (in this case, the releveant
> > code point is in _g_list_remove_link).
>
>
> Better a tiny bit of code bloat than API bloat. I can't see
> having separate delete_link() and delete_head() with the
> difference of delete_head() being that it only works for the
> head of the list.
>  
> [...]
> > 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.

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 free_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....
-- cheers, guido                     counter.li.org #81555