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

[Owen Taylor <otaylor redhat com>]

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

> Owen Taylor wrote:
> > 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.
> 
> the gtk.org docs say that feature requests shall be
> sent to gtk-list gnome org, and so I did. 

Which docs? File a bug about them... ;-)

That would have been accurate 4 years ago or so, but isn't
any more. The GLib README includes up to date information, as 
does the GTK+ FAQ.       

> The items
> that I am going post are actually the result of a
> code review and experiences with glib, I am not sure
> if there is a need to file them just to have them
> seen closed immediatly.

It's no harder to file a bug than to send a mail. And
if you send the mail, especially to gtk-list, there is
a good chance that we'll simply not see it or forget about it.
Which isn't a good use of your time, I don't think.
 
> > 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.
 
> The 04 notification

What is an O4 notification?

>  shall simply tell you that there is room
> for a better way of supporting this common operation. Otherwise,
> just delete free_1 and see what your developers say.

We make incompatible changes _very_ reluctantly, even between
major versions where they would be possible.

Regards,
                                        Owen