Learn how to code with the rust book

Ownership and Memory Safety in Rust

Learning Rust with Bitcoin

Ownership and Memory Safety in Rust

Understanding Rust's Unique Approach to Memory Management
The Ownership System: Rules and Principles
Moving Ownership and Memory Layout
References and Borrowing
String Types and Slices
Arrays, Vectors, and Generic Slices

Understanding Rust's Unique Approach to Memory Management

This chapter covers one of Rust's most important concepts. While previous concepts may have felt familiar to programmers coming from other languages, ownership is Rust's approach to solving memory safety without garbage collection.

Rust was designed with a fundamental goal of preventing memory-related bugs that plague low-level languages like C and C++. These issues include use-after-free bugs, where memory is accessed after it has been released, and buffer overflows, where programs write outside allocated memory boundaries. Traditional solutions to these problems have involved trade-offs that Rust seeks to eliminate. Higher-level languages like Java and Go solve memory safety through garbage collection, where an automatic process periodically identifies and frees unused memory. However, garbage collectors introduce performance overhead and can cause unpredictable pauses during program execution, making them unsuitable for systems programming where consistent performance is critical.

Rust achieves memory safety primarily through static analysis performed at compile time. The compiler examines source code and can determine whether most memory operations are safe without requiring garbage collection. For cases that cannot be verified statically—such as array access with runtime-computed indices—Rust inserts bounds checks that panic rather than allow undefined behavior. This approach differs fundamentally from static analyzers available for C and C++, which were retrofitted onto languages not originally designed for comprehensive static analysis. Rust's syntax and language rules were crafted from the ground up to enable extensive compile-time verification, ensuring that once a program compiles successfully, it will either run safely or panic predictably rather than exhibit undefined behavior.

The Ownership System: Rules and Principles

The cornerstone of Rust's memory safety guarantees is the ownership system, which governs how memory is managed throughout a program's is already installedexecution. Ownership operates on three fundamental rules that the compiler enforces at all times:

Each value in Rust has an owner (a variable that holds the value)
There can only be one owner at a time
When the owner goes out of scope, the value is dropped

Scopes in Rust are typically defined by curly braces, whether in function bodies, conditional blocks, or explicitly created scope blocks. When a variable is declared within a scope, that scope becomes the owner of the variable's value. The variable remains accessible and valid throughout the scope's lifetime, but as soon as execution leaves the scope, all owned variables are automatically cleaned up through a process called dropping.

This automatic cleanup is implemented through Rust's drop mechanism, where the language implicitly calls a drop function on variables going out of scope. For basic types, this simply means the memory is marked as available for reuse. For more complex types that manage resources, custom drop implementations can perform additional cleanup operations, such as closing file handles or releasing network connections. This pattern, borrowed from C++'s RAII (Resource Acquisition Is Initialization), ensures that resources are always properly released without requiring explicit cleanup code from the programmer.

Moving Ownership and Memory Layout

Understanding how ownership transfers between variables requires examining the difference between simple types and complex types in terms of memory layout and copying behavior. Simple types like integers, booleans, and floating-point numbers have a fixed, known size at compile time and can be efficiently copied. When you assign one integer variable to another, Rust creates a complete, independent copy of the value, allowing both variables to exist simultaneously without any ownership concerns.

Complex types like strings present a different challenge because they manage dynamically allocated memory. A String in Rust consists of three components stored on the stack: a pointer to heap-allocated character data, the current length of the string, and the total capacity of the allocated buffer. This structure allows strings to grow and shrink efficiently while maintaining knowledge of their boundaries. When you assign one String variable to another, Rust faces a choice: it could copy just the stack-based structure (creating two pointers to the same heap data) or perform a deep copy of all the heap data.

Rust's default behavior is to move ownership rather than copy, transferring the heap data from the source variable to the destination variable and invalidating the source. This approach prevents the dangerous scenario where multiple variables could modify the same heap memory or where the same memory could be freed multiple times when variables go out of scope. The move operation is efficient because it only copies the small stack-based structure, not the potentially large heap data, while maintaining memory safety by ensuring single ownership.

References and Borrowing

While ownership moves provide safety, they can be restrictive when you need to use a value in multiple places without transferring ownership. Rust addresses this through borrowing, which allows functions and variables to temporarily access data without taking ownership. A reference, created using the ampersand operator, provides read-only access to a value while leaving ownership with the original variable.

References enable functions to operate on data without consuming it, making it possible to use the same value multiple times throughout a program. When you pass a reference to a function, you're lending the data temporarily, and the function must return the reference before the original owner can regain full control. This borrowing metaphor reflects the temporary nature of the access: just as you might lend a book to a friend while retaining ownership, references allow temporary access while preserving the original ownership relationship.

Mutable references extend this concept to allow modification of borrowed data, but with strict restrictions to maintain safety. Rust permits only one mutable reference to a piece of data at any given time, preventing data races where multiple parts of a program might simultaneously modify the same memory. Additionally, you cannot have both mutable and immutable references to the same data simultaneously, as this could lead to situations where code assumes data is stable while other code is actively modifying it. These rules are enforced at compile time, eliminating entire classes of concurrency bugs that plague other systems programming languages.

fn main() {
    let mut wallet_balance: u64 = 100_000; // 100,000 satoshis

    // Immutable borrow: read the balance
    let balance_ref = &wallet_balance;
    println!("Current balance: {} sats", balance_ref);
    // balance_ref goes out of scope here

    // Mutable borrow: update the balance
    let balance_mut = &mut wallet_balance;
    *balance_mut += 50_000; // Receive payment
    println!("After deposit: {} sats", balance_mut);
    // balance_mut goes out of scope here

    // Function that borrows immutably
    fn display_balance(balance: &u64) {
        println!("Balance check: {} sats", balance);
    }

    // Function that borrows mutably
    fn deduct_fee(balance: &mut u64, fee: u64) {
        *balance -= fee;
    }

    display_balance(&wallet_balance);
    deduct_fee(&mut wallet_balance, 1_000);
    println!("After fee: {} sats", wallet_balance); // 149,000
}

String Types and Slices

Rust distinguishes between string literals and the String type, reflecting different memory management strategies and use cases. String literals are embedded directly in the compiled binary and have the type &str (string slice), representing a view into immutable string data. These literals are efficient because they require no runtime allocation, but they cannot be modified since they're part of the program's code.

The String type, in contrast, manages dynamically allocated memory and can grow, shrink, and be modified at runtime. You can create a String from a literal using String::from() or similar methods, which allocates heap memory and copies the literal's content. This distinction allows Rust to optimize for both performance (using literals when possible) and flexibility (using String when modification is needed).

String slices (&str) provide a powerful abstraction for working with portions of strings without copying data. A slice contains a pointer to the start of the string data and a length, allowing you to reference substrings efficiently. The slice syntax uses ranges (e.g., &s[0..5]) to specify which portion of the string to reference. Because slices are references, they're subject to borrowing rules, preventing the underlying string from being modified while slices exist. This compile-time enforcement prevents common bugs like accessing invalid memory after the original string has been freed or modified.

Arrays, Vectors, and Generic Slices

The slice concept extends beyond strings to any sequence of elements, providing a unified way to work with both fixed-size arrays and dynamic vectors. Arrays in Rust have their length encoded in their type (e.g., [i32; 5] for an array of five 32-bit integers), making them suitable for situations requiring compile-time size guarantees. Functions that accept arrays can enforce exact length requirements, useful for operations like cryptographic functions that need precisely sized inputs.

Slices (&[T]) provide a more flexible alternative, representing a view into any contiguous sequence of elements regardless of the underlying storage. You can create slices from arrays, vectors, or other slices, and the same slice can reference different portions of data throughout its lifetime. This flexibility makes slices ideal for functions that need to process sequences without caring about the specific storage mechanism or exact size.

The relationship between owned types (String, Vec<T>) and their borrowed slice counterparts (&str, &[T]) follows a consistent pattern throughout Rust. Owned types manage their memory and can be modified, while slices provide efficient, read-only access to portions of that data. This design enables APIs that are both flexible (accepting various input types through slices) and efficient (avoiding unnecessary copying), while maintaining Rust's safety guarantees through the borrowing system.

Quiz

dev3032.2

1/5

What is the main difference between a String and a string literal (&str) in Rust?