Re: [gmime-devel] g_mime_header_list_clear leaving a list in limbo

[stedfast comcast net]

Hi Ludo,

Can you write a small test case for the g_mime_header_iter_remove() bug that you are seeing?

I've got a Linux VM set up at the office that I can try to debug on while I try to figure out what is

wrong with my desktop at home.

There's no need to check/update tailpred in list_unlink() because of the way the linked list is

designed (using aliases). Of course, it requires gcc -fno-strict-aliasing to be used since

gcc 4.4 or so.

At some point I should re-work list.c to not require -fno-strict-aliasing (I've been working on other

areas where I use similar aliasing tricks), but as long as -fno-strict-aliasing continues to work,

I am not in a huge rush.

For example, check this out:

typedef struct _ListNode {

    struct _ListNode *next;

    int id;

} ListNode;

ListNode *list, *tail, *node;

int i;

list = NULL;

tail = (ListNode *) &list;

for (i = 0; i < 10; i++) {

    node = malloc (sizeof (ListNode));

    node->id = i;

    tail->next = node;

    tail = node;

}

tail->next = NULL;

Do you see the simplicity there? It's beautiful! No need to check if tail is NULL in the first

iteration of the loop because assigning to tail->next will assign to list (only works because

ListNode.next is the first member of the struct).

This is how list.c works as well, except that it's a doubly-linked list.

Jeff

---

From: "Ludo Brands" <ludo brands free fr>
To: stedfast comcast net
Cc: gmime-devel-list gnome org
Sent: Monday, November 26, 2012 7:13:25 AM
Subject: Re: [gmime-devel] g_mime_header_list_clear leaving a list in limbo

Hi Jeff,
>
> (I'd normally use inline comments, but my computer died on me the
> second time in 6 months, so I'm having to use a lame webmail interface
> to reply to email)
>
Ouch
> The problem with the g_mime_header_list_clear() is that it isn't
> removing the linked-list nodes as it frees them. Oops. There should be
> a list_unlink() call on each header before it is free'd. Another
> option is that it should call list_init() after freeing all the nodes.
>
OK
> I'm not sure what is going wrong with g_mime_header_iter_remove() and
> because of my dead linux box, I can't easily run it in a debugger at
> the moment. I'll try to look into it as soon as I figure out why my
> machine won't boot and install a replacement component.
>
In list.c is a list_unlink_tail() that updates list->tailpred; but it
that is never used. Similar for list_unlink_head. Perhaps a simple test
for tail or head in list_unlink() would be a solution.

> Good catch on the g_mime_header_list_prepend() using list_append().
> I'll commit a fix for this as soon as I send out this email.
>
> Jeff
Ok, thanks

Ludo