[SOLVED] What is Safety?

not_a_comp_scientist · November 24, 2016, 4:45pm

All through the literature on Rust there is mention of Safety.
But what is Safety?
I think of Safety as protection from evil-doers on the Internet but apparently in the context of writing Rust code, it has to do with computational errors; memory leaks maybe or something.
If Rust is so safe then what is it safe from?

I am not a computer scientist.

ExpHP · November 24, 2016, 5:53pm

Purely from a standpoint of terminology, generally, "safety" in Rust means safe from undefined behavior.

Basically, undefined behavior is a contract on the programmer; a compiler promises to produce a reasonably efficient program that performs the instructions written in the code on the condition that the programmer doesn't do X. The compiler has no obligation to verify that X never occurs (because it may be impossible), and it is given free reign to do anything if it does occur.

This makes bugs caused by undefined behavior often extremely difficult to debug.

Now of course, ultimately this definition doesn't say much, since the definition of "undefined behavior" depends on the language, and behavior which is "defined but clearly nonsense" (see == in JavaScript) is not much better!

So moving away from terminology: Personally, when I call Rust a safe language, I mean that Rust is safer from mistakes. Rust forces me to think upfront about many edge cases that I would otherwise forget about, because it has many good abstractions that encourage correct thinking.

In the end, I find that code I write in rust has fewer bugs to debug than similar code in C/C++, and is more likely to work properly on the first run.

No doubt this is very different from your definition of "safe!"

llogiq · November 24, 2016, 5:56pm

Safety from out-of-bounds reads/writes, use-after-free, null pointer dereference and data races. All of the above lead to potentially exploitable behavior.

stebalien · November 24, 2016, 6:00pm

Unless you explicitly opt-in to unsafe behavior (using an unsafe block), access to program state will be constrained by the type system.

For example, consider the following code:

mod non_zero {
    pub struct NonZero {
        value: u32,
    }
    impl NonZero {
        pub fn new(value: u32) -> NonZero {
            if value == 0 {
                panic!("Tried to construct a NonZero with a zero value");
            }
            NonZero { value: value }
        }
        pub fn set(&mut self, value: u32) {
            if value == 0 {
                panic!("Tried to write a zero to a NonZero");
            }
            self.value = value;
        }
        pub fn get(&self) -> u32 {
            self.value
        }
    }
}

fn main() {
    use self::non_zero::NonZero;
    // Here we can *only* call public methods on `NonZero`. We can't mess with the internals without using `unsafe`.
    /* ... do something ... */
}

Assuming there's no other code in the non_zero module, rust guarantees that calling the get() method on a NonZero will never return a zero (unless you use an unsafe block^†) because there's no way to set it to zero using a public method on NonZero.

^†It's also possible to exploit a bug in the rust compiler, LLVM, or, ask the operating system to mess with your program's memory.

steveklabnik · November 24, 2016, 6:01pm

The Rust Reference has moved is the documentation on this.

Unsafe operations are those that potentially violate the memory-safety guarantees of Rust's static semantics.

notriddle · November 24, 2016, 6:04pm

Data races
Dereferencing a null/dangling raw pointer
Reads of undef (uninitialized) memory
Breaking the pointer aliasing rules with raw pointers (a subset of the rules used by C)
&mut T and &T follow LLVM’s scoped noalias model, except if the &T contains an UnsafeCell<U>. Unsafe code must not violate these aliasing guarantees.
Mutating non-mutable data (that is, data reached through a shared reference or data owned by a let binding), unless that data is contained within an UnsafeCell.
Invoking undefined behavior via compiler intrinsics:
- Indexing outside of the bounds of an object with std::ptr::offset (offset intrinsic), with the exception of one byte past the end which is permitted.
- Using std::ptr::copy_nonoverlapping_memory (memcpy32/memcpy64 intrinsics) on overlapping buffers
Invalid values in primitive types, even in private fields/locals:
- Dangling/null references or boxes
- A value other than false (0) or true (1) in a bool
- A discriminant in an enum not included in the type definition
- A value in a char which is a surrogate or above char::MAX
- Non-UTF-8 byte sequences in a str
Unwinding into Rust from foreign code or unwinding from Rust into foreign code. Rust's failure system is not compatible with exception handling in other languages. Unwinding must be caught and handled at FFI boundaries.

not_a_comp_scientist · November 24, 2016, 6:12pm

Thanks to all.
I would mark this issue as closed if I could find a way.