3 ms·

> That's false, code outside of an unsafe block can generate undefined behavior by calling unsafe code that was not written safely. Is there any way to write s

• sidlls 9y ago
  Yes. To guarantee complete rust-safety, modulo LLVM bugs, do not use any Rust code that has unsafe blocks in it (this includes any code that has memory allocations, such as Vec). Less strictly one can refuse to use code with unsafe blocks that has not been thoroughly vetted by experts. Things like Vec may therefore be used depending on how strict one's definition of "vetted by experts" is, but rolling one's own "unsafe" block code is not allowed. I write rust-safe code all the time using the second standard, even though under the covers it's littered with unsafe.
  • Jhsto 9y ago
    Thanks for all the replies! So, while it's possible to manually check the use of unsafe, there is no way I can currently do it automatically, right? I noticed there is a #![forbid(unsafe_code)], which I can add to my source file, but this does not check that whatever functions I am importing or calling do not underlyingly use unsafe, right? Moreover, I admit I am being lazy here, but any idea whether there are sub-communities in Rust that are keen on creating these kinds of safe programs?
    • burntsushi 9y ago
      At some point, in the context of developing on commodity hardware using mainstream operating systems, you need to trust something and use unsafe. There's no way around it. People have varying tolerances on the use of unsafe code. I'm not aware of any coherent sub-community with a fundamentalist take on it though. My own personal tolerance is "when using it, carefully justify it." Generally, this takes the form of making the code run faster. Otherwise, I'll sacrifice almost everything else to avoid unsafe. Thankfully, said sacrifices are neither common nor arduous (in my experience).
      • kbenson 9y ago
        To the GP, also note that there is a distinction between what Rust is able to confirm is safe with the compiler and what is or is not necessarily safe. An unsafe block carefully vetted to be implemented correctly with a formally proven safe algorithm may still be safe in the general sense, if not save in the Rust compiler enforced sense. Indeed, that's one of the major reasons for using unsafe blocks, so foregoing them entirely may be unduly hamstringing yourself for no reason.
• oconnor663 9y ago
  This tldr-counter-tldr discussion is circling around this subtle issue: Unsafe code has a "contaminating" effect on the module it's in. For example, consider the length of a Vec. That's just an integer. Any method on Vec could change that integer without needing an unsafe block. However, increasing the length incorrectly (for example, past the allocated capacity) will totally cause UB, because unsafe code in other methods of Vec assumes the length is correct. Vec is able to expose a safe API, because the length is a private member, and callers can't set it willy-nilly. But code inside the Vec module needs to be very careful, even when it's not explicitly using unsafe blocks.
  • protomikron 9y ago
    Is it possibly to model that efficiently with a total programming language - or do we need a turing-complete language to write a feature-rich vector (or array, matrix, `Vector a N`, etc.) library? I sometimes wonder if we should maybe invest more in non-turing-complete language research. Obviously Haskell (and Rust) are improvements to the status-quo (critical code can be guarded explicitely via unsafe attributes and written by experts), but maybe this does not go far enough.
    • oconnor663 9y ago
      I'm not sure if this is directly related to what you're thinking about or not, but I think some of Rust's stdlib has been formally verified. It might be that more work in formal verification can get us the guarantees we want, without needing to change the language itself.
• TheDong 9y ago
  This is well-said in the article: If the 'unsafe' blocks contain their unsafety correctly (thus being 'safe' 'unsafe' blocks using the two different meanings of safe the article discusses), then using them is fine. The rust stdlib has a promise that all of their 'unsafe' blocks not marked as unsafe are 'safe', so using the stdlib you're writing 'safe' code (though it's possible it's unsafe if there are stdlib/compiler bugs). As the article explains, it's very nounced and, while imperfect, still a damn sight better than C++.