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

[Owen Taylor <otaylor redhat com>]

If you want to make feature enhancment requests, the 
best procedure is:

 - File them in bugzilla
 - (optional) send mail to gtk-devel-list if you think
   that discussion on the issue would be good.

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.

Regards,
                                        Owen


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

> The glib2 function g_list_free_1 is currently defined as
> void     g_list_free_1         (GList            *list);
> 
> This is not the best option, the function is actually
> called in many places to free the head of a glist. In
> about *all* places that includes an iteration on to the
> ->next list item.
> 
> Currently, all these places make up their own tmp variable
> to store the ->next pointer for the iteration, ie. they
> do something like
>     GList* tmp = list->next;
>     g_list_free_1 (list);
>     list = tmp;
> 
> All these code points may be collapsed if the g_list_free_1
> function would be redeclared to return the ->next pointer
> all by itself, with the code parts becoming simply:
>     list = g_list_free_1 (list);
> 
> Looking at the implementation of g_list_free_1, a developer
> can easily see that the ->next value is accessed anyway, so
> it would not be problematic to load the ->next value into
> the return-register.
> 
> GList*     g_list_free_1         (GList            *list);
> 
> In effect, the glib code would be smaller, faster, more
> readable, and consequently maintainable. Old code may
> still ignore the return value, so that a change has only
> minimal effect on existing code.