The developer wanted the second loop to use the data items, but is never executed.

Moreover, if the second loop was corrected, the fact that the developer wants to free the items and the list would lead to a crash…

So it’s just not the developer wanted to do, which was it seems something like this :

GList *list = e_vcard_get_attributes (evcard);
GList *l;
for (l = list; l != NULL; l = l->next)
{
/* Do something */
/* Do something else */
}

But Marco, what went wrong about that code? The second loop doesn’t run, g_free (NULL) is fine too. So it should just work (even though it looks very bad).

I don’t know much about using GLib (but I do know how a linked list works!), but on top of what Marco said was wrong about the iteration itself (which you can screw up in C++ in a few ways, most easily by modifying the list itself while iterating, if you’re not careful), imagining that he moved the unref to the first list or correctly kept a copy of the head pointer, he would be leaving behind what would look like a populated list, full of dangling pointers to memory that has (probably, it’s a refcount, after all) been freed. If he’s going to delete the items, he should also delete the list nodes.

Most of all, he doesn’t understand ownership correctly, not having bothered to check who’s the owner of e_vcard_get_attributes()’s return value. There’s an advantage to C++ here in theory, since in C you have to check the documentation, or the code of that function in order to know whether you take ownership or not, but in C++ you can codify it with smart pointers, and figure it out simply looking at the function signature. But this guy, if he wrote a function like e_vcard_get_attributes(), he’d probably used shared_ptr everywhere, using the “big hammer that works most of the time (but gives the nearly impossible to debug memory leaks sometimes, oh well)”, because he simply doesn’t understand ownership.

C++ and fancy smart pointers don’t free you from having to understand what’s going on, it just helps with the tedium of dealing with the details. You can just say “this object should be owned by a single owner at all time” by using a scoped_ptr, and let the compiler enforce this.

You still have to know you want this in the first place, though!

list<anobject>& lst = evcard.attributes();

for (lst = lst.begin(); lst != lst.end(); ++lst) // doesn’t compile
{
}

delete lst; // doesn’t compile

This clearly has no chance of compiling, unlike the C version.

either that, or c++ really don’t have anything better to do.

Where next points to the next element or to NULL if you are at the end of the least. prev points to the previous element or NULL if it is already the first element.
So just NULL means an empty list.
This is basically the standard way to implement lists, of course high level languages hide this well.

To iterate a list you just do
for (l = list; l != NULL; l = l->next)
{
}

So at the end of the iteration l will be NULL (i.e. empty list) and calling g_list_first on NULL returns NULL.

The two loops seem to have no reason to exist, they should be merged in one single loop doing all the work, an I think calling g_list_first isn’t even necessary, as e_vcard_get_attributes must be smart enough to give you the head of the list…

for (GList* node = g_list_first(list); node != NULL; node = g_list_next(node))
{
}