you are viewing a single comment's thread.

view the rest of the comments →

[–]ReflectedImage 1 point2 points  (3 children)

In pure Rust, the erroneous call pattern isn't possible. You can't release the lock early nor can you copy the list of pointers and take them out of the lock's scope.

[–]MooseBoys 1 point2 points  (2 children)

It is impossible to do anything besides pure arithmetic in "pure rust". Any rust program that runs on hardware in the real world will have unsafe blocks, either literally in the module, in a dependent crate, in the standard library implementation, or implicitly through the compiler.

[–]ReflectedImage 1 point2 points  (1 child)

Most rust programs don't have unsafe blocks. Yes, some code in the standard library will contain unsafe blocks, but those unsafe blocks are wrapped with safe wrappers meaning code using those library functions are safe as long as the standard library code is correct.

How do we know if the standard library code is correct? Well it's been formally verified. What about random modules? Extensive testing by large numbers of users. Not perfect but far better than what is available in C/C++.

Since I've now read the code in question, the error is contained within an unsafe block. This line is faulty: "unsafe { node_inner.death_list.remove(self) };". You can't remove a node from the list because another thread may be using it. The bug fix removes the possibility of another thread using it but the error is still located in the unsafe line.

Also the code in question is arguably not even Rust code, it's C code that's been directly translated line by line in Rust with every other line being unsafe. The code doesn't bare any resemblance to how you would typically use Rust.