Administrivia

• “Lab 0: Rustlings” is due (DUE: Jan 20 in one week!)
• Perpetration: Rpi 3 + sdcard + reader (from Lab 1)
• TA office hours
  • Fri at Coda C0915, 10-11 AM, Yechan Bae
  • Tue at Coda C0906, 05-06 PM, Sujin Park
  • Wed at Coda C1008, 11-12 PM, Mansour Alharthi

Q&A

1. About Rust’s safety and trade-offs:

Is an OS made in Rust still susceptible to as many CVEs as an OS made in C or C++? If not, what is the tradeoff (lines of code, performance e.g. HLL tax, etc.) to make it safer?

1. What’s POSIX (see, POSIX)?
2. About Rust vs. GC-based HLL or C in performance? (→ Lec 3)
3. About Rust vs. other approaches in memory safety? (→ Lec 2)
4. How do macros work? (→ Lec 4 or Lec 8)

Summary: Thinking of Rust

• RAII/OBRM
• Substructure Type System
• Ownership and Borrowing ← discussing in depth today!
  1. Rule 1. there can be many outstanding shared references
  2. Rule 2. There should be only one mutable reference
  3. Safety rule: Rule 1 xor Rule 2

Agenda

• Variable, value and type
• Ownership and borrowing
• Move and copy semantics
• Lifetime

Type, Variable and Value

//
//      +--> variable name (or identifier)
//      |
let mut x: i32 = 1;
//  +--    ---   +-> value
//  |      |
//  |      +--> type (32-bit signed integer)
//  +--> noting mutability
//
x = 2;

Trick to ask Rustc about a type of variable

let mut x: i32 = 1;

let _: () = 1; // what's _ and ()?
let _: () = x;

Variable and type

Value and type

Getting the size of variable and type

let x: i32 = 1;
let y: String = String::from("hello");

dbg!(std::mem::size_of_val(&x));     //=>  4
dbg!(std::mem::size_of_val(&y));     //=> 24

dbg!(std::mem::size_of::<i32>());    //=>  4
dbg!(std::mem::size_of::<String>()); //=> 24

Strongly typed programming language

• x: i32 is initialized with 1: i32 (not valid syntax)
• x: i32 is assigned with 2: i32 (not valid syntax)
• i32 of a variable and i32 of a value should be matched!

// x stores a value (1 :i32)
let mut x: i32 = 1;

// x is assigned with a value (2 :i32)
x = 2;

Assigning a value to a variable

Ownership and move semantics

• A variable owns a value: the owner is in charge of reclaiming the memory
• Ownership changes upon a move (e.g., y → x)

let mut x = String::from("Hello!");
let y = String::from("World!");

// y's value is moved to, now x owns "World!"
x = y;

Behind the move operation

{
    // x <- alloc("Hello!")
    let mut x = String::from("Hello!");

    // y <- alloc("World!")
    let y = String::from("World!");

    // drop(x): free("Hello!")
    x = y;

    ...
} 
// drop(x): free("World!")

1) Behind the move: allocation

• Allocating two local variables (e.g., cargo asm --rust)
• Note: x @rsp, y @rsp+40

2) Behind the move: drop and copy

• Dropping before an assignment (x @rsp)
• Copying a variable bit-by-bit (@rsp+40 → @rsp)

3) Out-of-scope: drop

• Dropping when it goes out of scope (x at @rsp)
• Reclaiming storage for variables (i.e., stack unwinding)

ORBM: Ownership Based Resource Mgmt

• x/y owns a string, which uniquely owns an array of chars
• OBRM: drop() frees the memory that the variable is in charge of

Re-using uninitialized variables

• Reintroducing y with let:

let y = String::from("World!");

x = y;

let y = String::from("New World!");

• If y is mutable, you can initialize it again:

let mut y = String::from("World!");

x = y;

y = String::from("New World!");

Example: transferring ownership

• Ownership can be transferred to a function (i.e., bind to a func param)
• Ownership can be transferred from a function (i.e., returned value)

// move a value from the caller to the callee
fn take(s: String) -> {}

// move a value from the callee to the caller
fn new() -> String { String::from("Hello") }

Example: transferring ownership

• Note, this is how drop<T>() is implemented!

fn take(s: String) -> {}

Example: transferring ownership

• Note, this is a typical constructor idiom

fn new() -> String { String::from("Hello") }

Ownership and copy semantics

let x = String::from("Hello!");
let y = x.clone();

Ownership and copy semantics

• It internally clones a vector containing “Hello!”
• And returns (i.e., moves) a new String to the caller

let x = String::from("Hello!");
let y = x.clone();

// @liballoc/string.rs
impl Clone for String {
  fn clone(&self) -> Self {
    String { vec: self.vec.clone() }
  }
}

Ownership and copy semantics

let x = String::from("Hello!");
let y = x.clone();

Copy semantics

• Primitive types (e.g., i32, i64) derive the Copy trait (see later in depth)

let x: i32 = 10;
let y = x; // copied! (not moved)

dbg!(x); // still readable!
dbg!(y);

Copy marker trait

• By default, variable bindings have move semantics
• Unless, its type implements std::marker::Copy (copy semantics)

// for custom types
#[derive(Copy, Clone)]
struct Foo;

// @core/marker.rs
impl Copy for u64 {}

impl_copy! {
  usize u8 u16 u32 u64 u128
  isize i8 i16 i32 i64 i128
  f32 f64
  bool char
}

How to program with this language?

• In practice, very tedious and inefficient (why no one using linear type before!)

fn len(s: String) -> usize { ... }

let x = String::from("Hello");

// move, so unable to access x after
let y = len(x);

// copy, so need to keep copying!
let y = len(x.clone())
dbg!(y);

How to program with this language?

• One way to avoid copying is transferring ownership back to the caller

fn len(s: String) -> (usize, String) { ... }

let x = String::from("Hello");

// transferring the ownership back-and-force
let (y, x) = len(x);

dbg!(x);
dbg!(y);

How String::len() is implemented then?

• It borrows a value (i.e., shared reference) from the caller

// @liballoc/string.rs
impl String {
    ...
    pub fn len(&self) -> usize {
        self.vec.len()
    }
}

Borrowing via references

• A variable borrows a value (i.e., shared reference) from an owner

let x = String::from("Hello");

// => String::len(&x) -> usize
let y = x.len();

// x is still accessible!
dbg!(x);

Note. . has lots of magic behind the scene (see, Nomicon 4.3 The Dot Operator)

Thinking of shared/mutable references

• Shared references → copy semantics
• Mutable references → move semantics (why?)

// => String::len(&x) -> usize
x.len();

// => String::push_str(&mut x, ...)
x.push_str("World!");

// @libcore/marker.rs
// &T follows copy semantics
impl Copy for &T {}

Rule 0. Borrowing via references

1. The owner should outlive all borrowers

let x = String::from("Hello");
let y = &x; // borrow a value for reading
let z = &x; // borrow a value for reading

drop(x);

dbg!(y);
dbg!(z);

Rule 0. Borrowing via references

1. Rule 0. The owner should outlive all borrowers

Rule 1. Borrowing via references

1. Rule 1. there can be many outstanding shared references

let x = String::from("Hello");
let y = &x; // borrow a value for reading
let z = &x; // borrow a value for reading

dbg!(z); //=> "Hello"
dbg!(y); //=> "Hello"
dbg!(x); //=> "Hello"

Rule 2. Borrowing via references

2. Rule 2. There should be only one mutable reference

let mut x = String::from("Hello");
let y = &mut x; // borrow a value for writing
let z = &mut x; // borrow a value for writing
...

Rule 3. Borrowing via references

3. Rule 3. Safety rule: {shared}+ xor mutable references

let mut x = String::from("Hello");
let y = &x;     // borrow a value for reading
let z = &mut x; // borrow a value for writing
...

Owned type: &str vs. String

let s = String::from("Hello"); // what's thye type of s?

let x = "Hello"; // what's the type of x?
let _: () = x;

Owned type: &str vs. String

• &str: a shared reference of a type str (i.e., [u8] ← Q. what’s this?)
• Guess what are the values in @rsp and @rsp+8?

let x = "Hello";

Owned type: &str vs. String

• Type doesn’t necessarily mean to have a concrete size (noted ?Sized or DST)
  • No way to store (copy/move) them into memory
  • Its value (T) is only referred via a reference (&T)
  • There exist a corresponding owner type (i.e., String for str)

dbg!(std::mem::size_of::<str>());
//=> error: `str` doesn't have a size known at compile-time
dbg!(std::mem::size_of::<&str>());   //=> 16

dbg!(std::mem::size_of::<String>()); //=> 24
dbg!(std::mem::size_of::<&String>());//=>  8

Example: benefit of owned type

• String abstracts a string it contains (so called, a container type)
• Again, there is no way we can store ?Sized like str into stack

let mut x = String::from("Hello");
x.push_str(" World!"); // Isn't the size of String changed?

dbg!(x);

Example: benefit of owned type

impl String {
    pub fn push_str(&mut self, string: &str) { .. }
    //              |
    //              +--> a mutable reference
}

let mut x = String::from("Hello");

{
  //=> String::push_str(&x, " World!")
  x.push_str(" World!");
}

dbg!(x);

Introducing a slice type (e.g., &str)

• Slice type, &[T] → borrows a contiguous list of elements
• Simply, (ptr, len): ptr points to the beginning element of the list

let x: &str = "Hello";

Example of a slice type

let x = String::from("Hello World");
let y = &x[0..5];

Thinking of memory safety

// in C++
std::string s = "Hello";
const char *c = s.c_str();

s.append(" World!");

std::cout << c;

// in Rust
let mut s = String::from("Hello");
let c = s.as_str();
    
s.push_str(" World!");

dbg!(c);

Memory safety by restricted aliasing

let mut s = String::from("Hello");
let c = s.as_str();
    
s.push_str(" World!");

dbg!(c);

Next lecture

• Next: Rust 3: Unsafety (and Safety)
• Don’t forget to submit answers to prep-questions (DUE: 10pm)
• “Lab 1: Rustlings” is due on Jan 27
• Perpetration: Rpi 3 + sdcard + reader (from Lab 1)

References

• Understanding Ownership
• Ownership and Lifetimes
• Lifetime Elision
• The Dot Operator