Dangling reference prevention in Rust - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Rust code?

Consider the following Rust code snippet. What will it print when run?

Rust

fn main() {
    let r;
    {
        let x = 5;
        r = &x;
    }
    println!("{}", r);
}

A Undefined behavior

B Compilation error due to borrowing rules

C Runtime error: dangling reference

D 5

💡 Hint

Think about the lifetime of x and the reference r.

The variable x is dropped at the end of the inner block, but r tries to borrow it outside that scope. Rust's borrow checker prevents this by causing a compile-time error, so the code does not compile.

🧠 Conceptual

intermediate

Which Rust feature prevents dangling references?

Which feature of Rust ensures that references do not outlive the data they point to, thus preventing dangling references?

A Borrow checker with lifetimes

B Ownership system

C Garbage collector

D Trait system

💡 Hint

It is a compile-time check related to how long references are valid.

The borrow checker uses lifetimes to ensure references do not outlive the data they point to, preventing dangling references at compile time.

🔧 Debug

advanced

Identify the cause of the compilation error

Why does this Rust code fail to compile?

Rust

fn get_str<'a>() -> &'a str {
    let s = String::from("hello");
    &s
}

A The function returns a reference to a local variable that is dropped after the function ends

B The string literal is not valid UTF-8

C Missing lifetime annotation on the return type

D The function should return a String, not a reference

💡 Hint

Consider the lifetime of s compared to the returned reference.

The variable s is created inside the function and dropped when the function ends. Returning a reference to it causes a dangling reference, which Rust forbids.

📝 Syntax

advanced

Which option correctly fixes the dangling reference error?

Given this code that does not compile, which option fixes the dangling reference issue?

fn get_str<'a>() -> &'a str {
    let s = String::from("hello");
    &s
}

A Add <code>static</code> lifetime to the return type: <code>&'static str</code>

B Remove the lifetime annotation from the return type

C Return a reference to a string literal instead of <code>s</code>

D Change the function to return <code>String</code> instead of a reference

💡 Hint

Think about ownership and how to avoid returning references to local variables.

Returning the owned String transfers ownership and avoids dangling references. Returning a reference to a local variable is invalid.

🚀 Application

expert

How many references are valid in this Rust code?

Analyze the following Rust code. How many references are valid and safe to use after the block ends?

Rust

fn main() {
    let r1;
    {
        let x = 10;
        r1 = &x;
    }
    let x2 = 20;
    let r2 = &x2;
    println!("{} {}", r1, r2);
}

A Neither r1 nor r2 is valid; both cause compile errors

B Both r1 and r2 are valid and print 10 20

C Only one reference (r2) is valid; r1 is invalid and causes compile error

D Both r1 and r2 are valid but r1 causes runtime error

💡 Hint

Consider the scope and lifetime of x and x2.

The reference r1 points to x which is dropped after the inner block, so r1 is invalid outside. r2 points to x2 which is valid in the outer scope.

Practice

1. What does Rust do to prevent dangling references?

easy

A. It automatically deletes all references after use.

B. It enforces borrowing rules and lifetimes to ensure references are valid.

C. It uses garbage collection to clean up unused references.

D. It allows references to point to any memory without checks.

Solution

1. Step 1: Understand what dangling references are

   Dangling references point to data that no longer exists, causing bugs.

2. Step 2: Identify Rust's prevention method

   Rust uses borrowing rules and lifetimes to ensure references are always valid while used.

3. Final Answer:

   It enforces borrowing rules and lifetimes to ensure references are valid. -> Option B

4. Quick Check:

   Dangling reference prevention = borrowing rules + lifetimes [OK]

Hint: Remember: Rust checks lifetimes to avoid invalid references [OK]

Common Mistakes:

• Thinking Rust uses garbage collection
• Believing references are deleted automatically
• Assuming Rust allows unchecked references

2. Which of the following Rust code snippets correctly prevents a dangling reference?

easy

A. let r;
{
let x = 5;
r = &x;
}
println!("{}", r);

B. let r = &5;
println!("{}", r);

C. let r = &x;
let x = 5;
println!("{}", r);

D. let x = 5;
let r = &x;
println!("{}", r);

Solution

1. Step 1: Analyze each snippet for lifetime validity

   let r; { let x = 5; r = &x; } println!("{}", r); creates a reference to x inside a block, but x is dropped before use, causing dangling reference. let r = &5; println!("{}", r); creates a reference to a temporary value 5, which is dropped while borrowed, causing compile error. let x = 5; let r = &x; println!("{}", r); creates x and r in the same scope, so r is valid. let r = &x; let x = 5; println!("{}", r); tries to reference x before x is declared, so x not in scope, compile error.

2. Step 2: Identify the snippet that correctly prevents dangling references

   let x = 5; let r = &x; println!("{}", r); is the correct example where the reference r points to x which lives long enough for r to be used safely.

3. Final Answer:

   let x = 5; let r = &x; println!("{}", r); -> Option D

4. Quick Check:

   Reference lifetime valid in same scope = let x = 5; let r = &x; println!("{}", r); [OK]

Hint: Keep referenced data alive in the same scope as the reference [OK]

Common Mistakes:

• Referencing variables that go out of scope too early
• Declaring references before the data they point to
• Assuming temporary values always live long enough

3. What will be the output of this Rust code?

fn main() {
    let r;
    {
        let x = 10;
        r = &x;
    }
    println!("{}", r);
}

medium

A. Compilation error due to dangling reference

B. 10

C. Undefined behavior at runtime

D. 0

Solution

1. Step 1: Understand variable lifetimes in the code

   Variable x is declared inside the inner block and dropped when the block ends. Reference r points to x but is used outside the block.

2. Step 2: Identify Rust's behavior on this code

   Rust's compiler detects that r would be a dangling reference because x does not live long enough. It will produce a compilation error.

3. Final Answer:

   Compilation error due to dangling reference -> Option A

4. Quick Check:

   Dangling reference causes compile error in Rust [OK]

Hint: References must not outlive the data they point to [OK]

Common Mistakes:

• Expecting code to run and print 10
• Thinking Rust allows unsafe dangling references
• Confusing runtime errors with compile-time errors

4. Identify the error in this Rust code and how to fix it:

fn get_ref() -> &i32 {
    let x = 42;
    &x
}

medium

A. Error: missing lifetime annotation. Fix by adding explicit lifetime.

B. No error, code is correct.

C. Error: returning reference to local variable. Fix by returning the value instead.

D. Error: x is not mutable. Fix by declaring x as mutable.

Solution

1. Step 1: Analyze the function's return type and variable scope

   The function returns a reference to an integer, but x is a local variable that is dropped when the function ends.

2. Step 2: Identify the problem and fix

   Returning a reference to a local variable causes a dangling reference. The fix is to return the value itself (i32) instead of a reference.

3. Final Answer:

   Error: returning reference to local variable. Fix by returning the value instead. -> Option C

4. Quick Check:

   Don't return references to local variables [OK]

Hint: Never return references to variables that go out of scope [OK]

Common Mistakes:

• Adding lifetimes without fixing the root cause
• Making variables mutable unnecessarily
• Ignoring that local variables are dropped after function ends

5. You want to return a reference to a string slice from a function without causing dangling references. Which approach is correct?

fn first_word(s: &String) -> &str {
    // ???
}

hard

A. Return a slice of s using lifetimes: &s[..1]

B. Create a new String inside the function and return a reference to it

C. Return a reference to a local string variable inside the function

D. Return the whole String by value instead of a reference

Solution

1. Step 1: Understand the input and output lifetimes

   The function takes a reference to a String and returns a string slice (&str) referencing part of that String.

2. Step 2: Choose the safe way to return a slice without dangling references

   Returning a slice of the input String (&s[..1]) is safe because the slice's lifetime is tied to the input reference's lifetime.

3. Final Answer:

   Return a slice of s using lifetimes: &s[..1] -> Option A

4. Quick Check:

   Return slices tied to input lifetimes to avoid dangling references [OK]

Hint: Return slices of input references, not local variables [OK]

Common Mistakes:

• Returning references to local variables
• Creating new owned Strings and returning references to them
• Ignoring lifetime relationships between input and output