4 ms·

I didn't follow all of it, but it sounds not so bad. 1 & 2 both involve unsafe code that, while possibly reasonable in a complex application, is obviously wron

I didn't follow all of it, but it sounds not so bad. 1 & 2 both involve unsafe code that, while possibly reasonable in a complex application, is obviously wrong in the simple case. Of course turning a reference into a mutable reference will cause trouble. Was Pin SUPPOSED to be resilient to unsafe code? In any case, seems like a bug in DerefMut and Clone, not Pin. The others are a bit more esoteric and do seem potentially concerning, but I'm not sure. But still, I'm left with my earlier question: just how resilient is Pin supposed to be?

kibwen 7y ago
> Was Pin SUPPOSED to be resilient to unsafe code? Regardless, for a user to be able to trigger undefined behavior without using the `unsafe` keyword indicates a bug here that must be fixed at the level of the language or standard library.
- eximius 7y ago
  But it does require unsafe? The implementation of DerefMut and Clone for the type being pinned require unsafe.
steveklabnik 7y ago
> Was Pin SUPPOSED to be resilient to unsafe code? Remember, unsafe does not mean "I can do whatever I want," it means "I am promising to uphold some guarantee on my own." That is, let's assume we have a function: /// Makes a new Foo. /// /// # Safety /// /// x must never be greater than 5 unsafe fn new(x: i32) -> Foo { and you write let x = 6; unsafe { new(x); } You have a bug, even though new is marked unsafe. In my understanding of the unsafe examples above, the unsafe code was upholding the invariants that it was required to uphold, and so would be more like having written `let x = 2;` in the above example, if that caused an issue, clearly there's a bug.
- eximius 7y ago
  I think this is a little too dumbed down for me to see the relevance to the actual problem. Also, I believ 1&2 both require unsafe code to implement the trait that allows the unsoundness. For what &T can I safely implement DerefMut? Is it the fault of Pin that a type has DerefMut implemented that the unsafe block of that implementation doesn't uphold safety?
  - steveklabnik 7y ago
    The relevance to the problem is that even if these examples needed unsafe code, that doesn't mean that there's no problem. "resilient to unsafe code" is not the right way to think about unsafe. > For what &T can I safely implement DerefMut? Is it the fault of Pin that a type has DerefMut implemented that the unsafe block of that implementation doesn't uphold safety? It is the fault of Pin's safety guidelines, which suggest a contract that is not actually enough to uphold safety. That's why this is considered an unsoundness in Pin, and not a problem with the code written with unsafe. That is: > that the unsafe block of that implementation doesn't uphold safety? is not correct, the unsafe block does everything it's supposed to to uphold safety.
    - eximius 7y ago
      I can see the argument that Pin should be safe if you meet the contract it claims to need. The requirements are not sufficiently tight. Fair enough.
TheDong 7y ago
It does not require any use of the unsafe keyword. See the playground link containing a demonstration of the issue: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=70b7b28b690e0020f52695b9e086f5c2 https://play.rust-lang.org/?version=stable&mode=debug&editio... The 'unsafe' keyword in the internals post is referring to the stdlib implementation of Pin. The stdlib's use of unsafe is supposed to uphold safety guarantees for all functions that aren't exposed as unsafe, and the stdlib failed the guarantee here, thus allowing a soundness bug without the user using 'unsafe' anywhere.

kibwen 7y ago

> Was Pin SUPPOSED to be resilient to unsafe code? Regardless, for a user to be able to trigger undefined behavior without using the `unsafe` keyword indicates a bug here that must be fixed at the level of the language or standard library.

eximius 7y ago
But it does require unsafe? The implementation of DerefMut and Clone for the type being pinned require unsafe.

steveklabnik 7y ago

> Was Pin SUPPOSED to be resilient to unsafe code? Remember, unsafe does not mean "I can do whatever I want," it means "I am promising to uphold some guarantee on my own." That is, let's assume we have a function: /// Makes a new Foo. /// /// # Safety /// /// x must never be greater than 5 unsafe fn new(x: i32) -> Foo { and you write let x = 6; unsafe { new(x); } You have a bug, even though new is marked unsafe. In my understanding of the unsafe examples above, the unsafe code was upholding the invariants that it was required to uphold, and so would be more like having written `let x = 2;` in the above example, if that caused an issue, clearly there's a bug.

eximius 7y ago
I think this is a little too dumbed down for me to see the relevance to the actual problem. Also, I believ 1&2 both require unsafe code to implement the trait that allows the unsoundness. For what &T can I safely implement DerefMut? Is it the fault of Pin that a type has DerefMut implemented that the unsafe block of that implementation doesn't uphold safety?
- steveklabnik 7y ago
  The relevance to the problem is that even if these examples needed unsafe code, that doesn't mean that there's no problem. "resilient to unsafe code" is not the right way to think about unsafe. > For what &T can I safely implement DerefMut? Is it the fault of Pin that a type has DerefMut implemented that the unsafe block of that implementation doesn't uphold safety? It is the fault of Pin's safety guidelines, which suggest a contract that is not actually enough to uphold safety. That's why this is considered an unsoundness in Pin, and not a problem with the code written with unsafe. That is: > that the unsafe block of that implementation doesn't uphold safety? is not correct, the unsafe block does everything it's supposed to to uphold safety.
  - eximius 7y ago
    I can see the argument that Pin should be safe if you meet the contract it claims to need. The requirements are not sufficiently tight. Fair enough.

TheDong 7y ago

It does not require any use of the unsafe keyword. See the playground link containing a demonstration of the issue: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=70b7b28b690e0020f52695b9e086f5c2 https://play.rust-lang.org/?version=stable&mode=debug&editio... The 'unsafe' keyword in the internals post is referring to the stdlib implementation of Pin. The stdlib's use of unsafe is supposed to uphold safety guarantees for all functions that aren't exposed as unsafe, and the stdlib failed the guarantee here, thus allowing a soundness bug without the user using 'unsafe' anywhere.