logoalt Hacker News

dijit • last Wednesday at 7:02 PM • 2 replies • view on HN

I think you missed the parents point. We all universally acknowledge the need for the unsafe{} keyword in general; what the parent is saying is: given the constraint of a lock, could this code not have obviated the need for an unsafe block entirely. Thus rendering the memory safety-issue impossible.

Replies

aw1621107 • last Wednesday at 7:26 PM

Ah, I see that interpretation now that you spelled it out for me.

Here's what `List::remove` says on its safety requirements [0]:

    /// Removes the provided item from this list and returns it.
    ///
    /// This returns `None` if the item is not in the list. (Note that by the safety requirements,
    /// this means that the item is not in any list.)
    ///
    /// # Safety
    ///
    /// `item` must not be in a different linked list (with the same id).
    pub unsafe fn remove(&mut self, item: &T) -> Option<ListArc<T, ID>> {
At least if I'm understanding things correctly, I don't think that that invariant is something that locks can protect in general. I can't say I'm familiar enough with the code to say whether some other code organization would have eliminated the need for the unsafe block in this specific case.

[0]: https://github.com/torvalds/linux/blob/3e0ae02ba831da2b70790...

Phelinofist • last Wednesday at 7:22 PM

Yes, that is what I meant - thanks for actually expressing my thoughts better than me.