Garrett Wollman wrote:

Reverting the change won't guarantee safety. In particular, in the remove case, the dereference of the "next" pointer in the removed element is highly dependent on what you do with the removed element. If you bzero it, then you will have a hell of a time dereferencing the pointer correctly.

The plan only works correctly where the queue element fields themselves are type-stable (i.e. they do not get reused to link them onto another queue, and they do not get reused for other purposes, or zeroed or filled in with WITNESS or INVARIANTS test values), and if the elements themselves are allocated out of type-stable memory, as part of maintaining that guarantee.

The iterator macros are ugly, in that they imply certain semantics, namely that they will work with the other macros that do element manipulations. This turns out not to be true, in the delete case. You could also come up with a failure scenario for tail insertion, or for head insertion, depending on your assumptions about whether or not an insertion while in the loop would result in the loop also doing work on an element, e.g.:

loop do_work_on_element(cur_element) if (new_element > cur_element) insert(new_element)

...whether or not the work gets done on the inserted element depends on the insertion method.

-- Terry

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message