5 ms·

The purpose of `unsafe` is for the compiler to assume a block of code is correct. SIMD intrinsics are marked as unsafe because they take raw pointers as argumen

The purpose of `unsafe` is for the compiler to assume a block of code is correct. SIMD intrinsics are marked as unsafe because they take raw pointers as arguments. In safe Rust (the default), memory access is validated by the borrow checker and type system. Rust’s goal of soundness means safe Rust should never cause out-of-bounds access, use-after-free, etc; if it does, then there's a bug in the Rust compiler.

no_wizard 2y ago
How do we know if Rust is safe unless Rust is written purely in safe Rust? Is that not true? Even validators have bugs or miss things no?
- steveklabnik 2y ago
  > Even validators have bugs Yep! For example, https://github.com/Speykious/cve-rs https://github.com/Speykious/cve-rs is an example of a bug in the Rust compiler, which allows something that it shouldn't. It's on its way to being fixed. > or miss things no? This is the trickier part! Yes, even proofs have axioms, that is, things that are accepted without proof, that the rest of the proof is built on top of. If an axiom is incorrect, so is the proof, even though we've proven it.
- TheDong 2y ago
  And while we're in the hypothetical extreme world somewhat separated from reality, a series of solar flares could flip a memory bit and all the error-correction bits in my ECC ram at once to change a pointer in memory, causing my safe rust to do an out of bounds write. Until we design perfectly correct computer hardware, processors, and a sun which doesn't produce solar radiation, we can't rely on totally uniform correct execution of our code, so we should give up. The reality is that while we can't prove the rust compiler is safe, we can keep using it and diligently fix any counter-examples, and that's good enough in practice. Over in the real world, where we can acknowledge "yes, it is impossible to prove the absence of all bugs" and simultaneously say "but things sure seem to be working great, so we can get on with life and fix em if/when they pop up".
  - no_wizard 2y ago
    I’m simply positing how do we know the safety guarantees hold, not a hypothetical extreme. Not really sure where the extreme comes in. If you take Rust at face value, than this to me seems like an obvious question to ask
    - TheDong 2y ago
      Sorry, it's just that I have an allergic reaction to what sounds like people trying to make debate-bro arguments. Like, when I say "use signal, it's secure", someone could respond "Ahh, but technically you can't prove the absence of bugs, signal could have serious bugs, so it's not secure, you fool", but like everyone reading this already knew "it's secure" means "based on current evidence and my opinion it seems likely to be more secure than alternatives", and it got shortened. Interpreting things as absolutes that are true or false is pointless debate-bro junk which lets you create strawmen out of normal human speech. When someone says "1+1 = 2", and a debate-bro responds "ahh but in base-2 it's 10 you fool", it's just useless internet noise. Sure, it's correct, but it's irrelevant, everyone already knows it, the original comment didn't mean otherwise. Responding to "safe Rust should never cause out-of-bounds access, use-after-free" with "ahh but we can't prove the compiler is safe, so rust isn't safe is it??" is a similarly sorta response. Everyone already knows it. It's self-evident. It adds nothing. It sounds like debate-bro "I want to argue with you so I'm saying something that's true, but we both already know and doesn't actually matter". I think that allergic response came out, apologies if it was misguided in this case and you're not being a debate-bro.
      - johnisgood 2y ago
        But you have to admit Rust zealots are misguided, too, who does not happen to know or realize the obviousness of what you just said with regarding to Rust.
        TheDong 2y ago
        Such a rust zealot is a strawman, though please don't let me stop you from enjoying burning such a strawman.
int_19h 2y ago
Out of curiosity, why do they take raw pointers as arguments, rather than references?
- steveklabnik 2y ago
  From the RFC: https://rust-lang.github.io/rfcs/2325-stable-simd.html https://rust-lang.github.io/rfcs/2325-stable-simd.html > The standard library will not deviate in naming or type signature of any intrinsic defined by an architecture. I think this makes sense, just like any other intrinsic: unsafe to use directly, but with safe wrappers. I believe that there are also some SIMD things that would have to inherently take raw pointers, as they work on pointers that aren't aligned, and/or otherwise not valid for references. In theory you could make only those take raw pointers, but I think the blanket policy of "follow upstream" is more important.
  - estebank 2y ago
    Which also doesn't preclude someone else writing an abstraction on top that provides an API using references.
    - steveklabnik 2y ago
      Absolutely, that's important too, thanks.

no_wizard 2y ago

How do we know if Rust is safe unless Rust is written purely in safe Rust? Is that not true? Even validators have bugs or miss things no?

steveklabnik 2y ago
> Even validators have bugs Yep! For example, https://github.com/Speykious/cve-rs https://github.com/Speykious/cve-rs is an example of a bug in the Rust compiler, which allows something that it shouldn't. It's on its way to being fixed. > or miss things no? This is the trickier part! Yes, even proofs have axioms, that is, things that are accepted without proof, that the rest of the proof is built on top of. If an axiom is incorrect, so is the proof, even though we've proven it.
TheDong 2y ago
And while we're in the hypothetical extreme world somewhat separated from reality, a series of solar flares could flip a memory bit and all the error-correction bits in my ECC ram at once to change a pointer in memory, causing my safe rust to do an out of bounds write. Until we design perfectly correct computer hardware, processors, and a sun which doesn't produce solar radiation, we can't rely on totally uniform correct execution of our code, so we should give up. The reality is that while we can't prove the rust compiler is safe, we can keep using it and diligently fix any counter-examples, and that's good enough in practice. Over in the real world, where we can acknowledge "yes, it is impossible to prove the absence of all bugs" and simultaneously say "but things sure seem to be working great, so we can get on with life and fix em if/when they pop up".
- no_wizard 2y ago
  I’m simply positing how do we know the safety guarantees hold, not a hypothetical extreme. Not really sure where the extreme comes in. If you take Rust at face value, than this to me seems like an obvious question to ask
  - TheDong 2y ago
    Sorry, it's just that I have an allergic reaction to what sounds like people trying to make debate-bro arguments. Like, when I say "use signal, it's secure", someone could respond "Ahh, but technically you can't prove the absence of bugs, signal could have serious bugs, so it's not secure, you fool", but like everyone reading this already knew "it's secure" means "based on current evidence and my opinion it seems likely to be more secure than alternatives", and it got shortened. Interpreting things as absolutes that are true or false is pointless debate-bro junk which lets you create strawmen out of normal human speech. When someone says "1+1 = 2", and a debate-bro responds "ahh but in base-2 it's 10 you fool", it's just useless internet noise. Sure, it's correct, but it's irrelevant, everyone already knows it, the original comment didn't mean otherwise. Responding to "safe Rust should never cause out-of-bounds access, use-after-free" with "ahh but we can't prove the compiler is safe, so rust isn't safe is it??" is a similarly sorta response. Everyone already knows it. It's self-evident. It adds nothing. It sounds like debate-bro "I want to argue with you so I'm saying something that's true, but we both already know and doesn't actually matter". I think that allergic response came out, apologies if it was misguided in this case and you're not being a debate-bro.
    - johnisgood 2y ago
      But you have to admit Rust zealots are misguided, too, who does not happen to know or realize the obviousness of what you just said with regarding to Rust.
      - TheDong 2y ago
        Such a rust zealot is a strawman, though please don't let me stop you from enjoying burning such a strawman.

int_19h 2y ago

Out of curiosity, why do they take raw pointers as arguments, rather than references?

steveklabnik 2y ago
From the RFC: https://rust-lang.github.io/rfcs/2325-stable-simd.html https://rust-lang.github.io/rfcs/2325-stable-simd.html > The standard library will not deviate in naming or type signature of any intrinsic defined by an architecture. I think this makes sense, just like any other intrinsic: unsafe to use directly, but with safe wrappers. I believe that there are also some SIMD things that would have to inherently take raw pointers, as they work on pointers that aren't aligned, and/or otherwise not valid for references. In theory you could make only those take raw pointers, but I think the blanket policy of "follow upstream" is more important.
- estebank 2y ago
  Which also doesn't preclude someone else writing an abstraction on top that provides an API using references.
  - steveklabnik 2y ago
    Absolutely, that's important too, thanks.