Unsafe Rust

Question 1

Why do unsafe rust exist?

Answer 1

Unsafe Rust exists because, by nature, static analysis is conservative. When the compiler tries to determine whether or not code upholds the guarantees, it’s better for it to reject some valid programs than to accept some invalid programs. Although the code might be okay, if the Rust compiler doesn’t have enough information to be confident, it will reject the code. In these cases, you can use unsafe code to tell the compiler, “Trust me, I know what I’m doing.” Be warned, however, that you use unsafe Rust at your own risk: if you use unsafe code incorrectly, problems can occur due to memory unsafety, such as null pointer dereferencing.

Another reason Rust has an unsafe alter ego is that the underlying computer hardware is inherently unsafe. If Rust didn’t let you do unsafe operations, you couldn’t do certain tasks. Rust needs to allow you to do low-level systems programming, such as directly interacting with the operating system or even writing your own operating system. Working with low-level systems programming is one of the goals of the language. Let’s explore what we can do with unsafe Rust and how to do it.

Question 2

What do unsafe allows us to do

Answer 2

1. Dereference a raw pointer
2. Call an unsafe function or method
3. Acess or modify a mutable static variable
4. implement an unsafe trait
5. Access fields of a union

Question 3

what does unsafe turn off

Answer 3

unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block.

Question 4

two types of raw pointer in unsafe rust

Answer 4

As with references, raw pointers can be immutable or mutable and are written as *const T and *mut T, respectively.

The asterisk isn’t the dereference operator; it’s part of the type name. In the context of raw pointers, immutable means that the pointer can’t be directly assigned to after being dereferenced.

Question 5

what makes raw pointers different from smart pointer

Answer 5

1. Are allowed to ignore the borrowing rules by having both immutable and mutable pointers or multiple mutable pointers to the same location
2. aren’t guaratneed to point to valid memory
3. are allowed to be null
4. dont implement any automatic cleanup

Question 6

why opt out of rust safety

Answer 6

you can give up guaranteed safety in exchange for greater performance or the ability to interface with another language or hardware where Rust’s guarantees don’t apply.

Question 7

Why is static variable / global variable not allowed in safe rust

Answer 7

in a multi threaded enviroment the static variable enables multiple thread to mutate the value and could result in data races.

Question 8

when to use unsafe code

Answer 8

using unsafe to take one of the five actions (superpowers) just discussed isn’t wrong or even frowned upon. But it is trickier to get unsafe code correct because the compiler can’t help uphold memory safety. When you have a reason to use unsafe code, you can do so, and having the explicit unsafe annotation makes it easier to track down the source of problems when they occur.

Question 9

Why do we need unsafe

Answer 9

lets us write code whose safety relies on invariants the compiler cannot check:

1. working with hardware devices
2. interacting with external code
3. writing concurrency primitives
4. overcoming borrow checker limitations
5. perfomance optimizations.

Question 10

what do we believe if we create an unsafe code

Answer 10

with unsafe, we tell the compiler that the code is ok because we checkd it manually. that is, we checkd that the code never violates the rust type system. we asserting that the unsafe code we wrote is safe

Question 11

What do compiler assume when u any code including unsafe code

Answer 11

The compiler always assumes all code follows rust safety rules that is, it assumes no code ever:

1. Dereferences dangling pointers
2. violates reference aliasing
3. causes unsychnronized data
4. produces an invalid value

Question 12

The effect of Incorrect unsafe code

Answer 12

usually incorrect unsafe means undefined behaviour

effects of undefined behaviour ranges from none to crashes to abritary data coruption. effect may not appear today but tomorrow

you should always avoid undefined behaviour

Question 13

What do u need to audit when using unsafe code

Answer 13

both unsafe and safe code