3 ms·
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 const
by dijit 11mo ago
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.
- Phelinofist 11mo agoYes, that is what I meant - thanks for actually expressing my thoughts better than me.
- aw1621107 11mo agoAh, 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/3e0ae02ba831da2b707905f4e602e43f8507b8cc/rust/kernel/list.rs#L582 https://github.com/torvalds/linux/blob/3e0ae02ba831da2b70790...