Messages in this thread | | | Date | Tue, 25 Mar 2008 03:15:40 -0400 (EDT) | From | "Robert P. J. Day" <> | Subject | list splicing and list POISONing |
| |
based on a conversation we've been having on the newbies list, i'm curious about the rationale behind list "POISON"ing.
from <linux/list.h>, when you splice one list into another, the head element from the original list is left hanging in space with its original prev and next pointer values unchanged:
=== static inline void __list_splice(struct list_head *list, struct list_head *head) { struct list_head *first = list->next; struct list_head *last = list->prev; struct list_head *at = head->next;
first->prev = head; head->next = first;
last->next = at; at->prev = last; } ===
notice how neither list->prev nor list->next is set to, say, NULL to represent that that list head now represents an empty list. instead, those pointers are left (rather dangerously) pointing into the newly-spliced list, which means that, if you erroneously try to traverse the list represented by the "list" list head, you'll end up immediately over in the new list and loop there forever. it would seem to make more sense to set those pointers to either NULL or LIST_POISON{1,2}, would it not? just for safety's sake?
it seems like that's what's done when an element is *deleted* (that is, unlinked) from a list:
=== static inline void list_del(struct list_head *entry) { __list_del(entry->prev, entry->next); entry->next = LIST_POISON1; entry->prev = LIST_POISON2; } ===
so shouldn't the same reasoning apply in the splicing example?
rday --
======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA ========================================================================
| |