On Thu, 2005-11-24 at 17:56 +0200, Kalle Vahlman wrote:
> 2005/11/24, Tim Janik <timj imendio com>:
> > On Thu, 24 Nov 2005, Owen Taylor wrote:
> >
> > > if (head) {
> > > g_list_append(tail, new);
> > > tail = tail->next;
> > > } else {
> > > head = tail = g_list_append(null, new);
> > > }
> > >
> > > strikes me as acceptable code, and I know there are some examples like this
> > > in GTK+. Maybe the gain is worth the pain ... unless someone is compiling
> > > production code with -Werror it isn't going to *break* a build, and there
> > > is no bin-compat issue. But it's definitely a compatibility break of some
> > > sort.
> >
> > i think one can argue both ways here, in the above code, i'd still write
> > head = g_list_append (tail, new); and recommend that people also do that,
> > because a) code is duplicated so often and this easily introduces errors
> > in another context, and b) i'd like to think of the list API as something
> > where i'm not allowed to ignore return values to avoid mistakes ;)
>
> Append and perpend already have a big fat NOTE stating:
>
> "The return value is the new start of the list, which may have
> changed, so make sure you store the new value."
>
> so I would consider anyone not doing it misusing the API. Thus this
> move would be just a case of enforcing correct API usage (a very wise
> move if you ask me). Specially since it's compile-time only.
The GList API isn't an opaque abstract data structure; it's a a set of
well-defined operations on list nodes. It would not be OK to change the
g_list_append() operation to modify the list in some different way,
no matter what is documented. (The API existed 3-4 years before the
docs after all.)
Regards,
Owen
Attachment:
signature.asc
Description: This is a digitally signed message part