Re: g_slist_foreach and g_list_foreach functions
- From: Tim Janik <timj gtk org>
- To: Darin Adler <darin eazel com>
- Cc: "Kuykendall, PR Paul (8807)" <KUYKENDAPR raytheon com>, "'gtk-devel-list gnome org'" <gtk-devel-list gnome org>, "Ray, TD Travis (8878)" <RAYTD raytheon com>
- Subject: Re: g_slist_foreach and g_list_foreach functions
- Date: Thu, 21 Sep 2000 06:56:29 +0200 (CEST)
On Wed, 13 Sep 2000, Darin Adler wrote:
> on 9/13/00 12:00 PM, Kuykendall, PR Paul (8807) at KUYKENDAPR raytheon com
> wrote:
>
> > I ran across a situation where the g_*list_foreach() functions quit
> > processing before finishing through the list.
> >
> > In the case of a function being called by g_*list_foreach() that removes the
> > current list element (via g_slist_remove() ), processing stops, due to the
> > node being freed. The small fix below seems to fix that problem, with a
> > minimal of effort. Sorry it isn't in diff format, but my that machine isn't
> > networked.
> >
> > Any reason why this type of fix couldn't be added?
>
> Your fix replaces one kind of anomaly (can't remove current element) with
> another kind of anomaly (can't remove subsequent element). So it's not a
> good idea to make this change -- it can break existing programs.
we generally don't support full reentrancy for everything, e.g.
things like list walks. but we at least try to care about the
case where the _current_ element is being removed.
the point in doing that trade, is that simply walking a list,
check elements and remove them, is a pretty common operation.
that's why pretty much all *_forall() implementations of our
containers conatin code ala:
GList *nnode = node->next;
callback (node->data);
node = nnode;
to cover up for that case. based on that, the proposed changes
for slist/list make a lot of sense.
> -- Darin
>
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]