Skip to content

15_unsafe: add scenario skeleton #82

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Dec 18, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions content/lessons/15_unsafe/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
+++
title = "Unsafe Rust"
date = 2024-12-18
weight = 1
[extra]
lesson_date = 2024-12-19
+++

# Unsafe Rust Alter Ego

So far, no operation in Rust that we performed could trigger UB (Undefined Behaviour):

- data races were prevented by _sharing XOR mutability_ borrow checker rule;
- use-after-free, dangling references, etc. were prevented by lifetimes & ownership.

But no respectable, powerful programming language can stand being constrained that much, in such a cage!

In Rust, `unsafe` keyworld unleashes the hidden superpowers.

### Unsafe superpowers

Inside a `unsafe { ... }` block, you can (and normally you can't):

- **Dereference a raw pointer,**
- **Call an unsafe function or method,**
- Access or modify a mutable static variable,
- Implement an unsafe trait,
- Access fields of a union.

The first superpower is the most important. (Efficient) implementation of many data structures would be impossible without ability to use raw pointers, as references don't allow circular dependencies, among other limitations.

## Reading

- [The Book, Chapter 19.1](https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html)

- [The Rustonomicon](https://doc.rust-lang.org/nomicon/), especially chapter 1 _(Meet Safe and Unsafe)_

- [How unpleasant is Unsafe Rust?](https://www.reddit.com/r/rust/comments/16i8lo2/how_unpleasant_is_unsafe_rust/)
100 changes: 100 additions & 0 deletions content/lessons/15_unsafe/unsafe_superpowers.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,100 @@
#![allow(unused_assignments)]
#![allow(unused_variables)]
#![allow(dead_code)]

/* unsafe superpower 1: dereferencing pointers. */
fn superpower_1() {
let x = 42;

// Implicit &T -> *const T conversion.
let raw_ptr: *const i32 = &x;

// An old way to directly create a pointer.
let raw_ptr: *const i32 = std::ptr::addr_of!(x);

// The new way to directly create a pointer.
let raw_ptr: *const i32 = &raw const x;

// Dereferencing a raw pointer requires an `unsafe` block.
println!("Value: {}", unsafe { *raw_ptr });
}

/* unsafe superpower 2: calling an unsafe function. */
unsafe fn unsafe_function() {
println!("This is an unsafe function!");
}

fn superpower_2() {
unsafe {
// Calling an unsafe function.
unsafe_function();
}
}

/* unsafe superpower 3: Accessing or modifying mutable static variable.
* It is unsafe because it can lead to data races if accessed concurrently.
* */

static mut COUNTER: i32 = 0;

fn increment_counter() {
unsafe {
// Accessing and modifying a mutable static variable
COUNTER += 1;
println!("Counter: {}", COUNTER);
}
}

fn superpower_3() {
// This would cause UB: a data race.
// std::thread::spawn(increment_counter);
increment_counter();
}

/* unsafe superpower 4: Implementing unsafe traits.
* It is unsafe because safe code is permitted to cause UB if an unsafe trait
* is implemented for a type that should not implement it (think Send/Sync).
* */

unsafe trait CanBeAtomic {
fn safe_method_of_unsafe_trait(&self);
}

struct MyStruct {
i: i32,
}

unsafe impl UnsafeTrait for MyStruct {
fn safe_method_of_unsafe_trait(&self) {
println!("Method called!");
}
}

fn superpower_4() {
let my_struct = MyStruct { i: 42 };

// Calling a safe method from an unsafe trait
my_struct.safe_method_of_unsafe_trait();
}

/* unsafe superpower 5: Accessing fields of a union.
* It is unsafe because union can contain a different variant that we try to read,
* so we could read some rubbish value.
* */

union MyUnion {
int_value: i32,
bool_value: bool,
}

fn main() {
let u = MyUnion { int_value: 42 };

unsafe {
// Accessing a field of a union
println!("Union value as int: {}", u.int_value);

// Would result in UB, as the compiler may assume that bool is either 0 or 1 underneath.
// println!("Union value as bool: {}", u.bool_value);
}
}
Loading