5
Reading Club: The Book - Ownership Inventory Quiz no 1 [PROJECT] (rust-book.cs.brown.edu)
submitted 2 years ago* (last edited 2 years ago) by maegul@lemmy.ml to c/learningrustandlemmy@lemmy.ml
6 comments fedilink hide all child comments

After Chs 5 and 6 (see the reading club post here), we get a capstone quiz that covers ownership along with struts and enums.

So, lets do the quiz together! If you've done it already, revisiting might still be very instructive! I certainly thought these questions were useful "revision".

I'll post a comment for each question with the answer, along with my own personal notes (and quotes from The Book if helpful), behind spoiler tags.

Feel free to try to answer in a comment before checking (if you dare). But the main point is to understand the point the question is making, so share any confusions/difficulties too, and of course any corrections of my comments/notes!.

all 7 comments
sorted by: hot top new old
[-] maegul@lemmy.ml 1 points 2 years ago

Q4: Method and Ownership

  • What best describes the compiler error
/// Gets the string out of an option if it exists,
/// returning a default otherwise
fn get_or_default(arg: &Option<String>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.unwrap();
    s.clone()
}
  1. arg does not live long enough
  2. cannot move out of arg in arg.unwrap()
  3. cannot call arg.is_none() without dereferencing arg
  4. cannot return s.clone() which does not live long enough

Answer

2

  • cannot move arg in arg.unwrap()
    • arg is a reference.
    • but unwrap() has signature unwrap(self) -> T: it takes ownership!
    • Therefore unwrap cannot take ownership (arg doesn't have ownership to move/give).

Context: The function Option::unwrap expects self, meaning it expects ownership of arg. However arg is an immutable reference to an option, so it cannot provide ownership of the option. Therefore the compiler complains that we cannot move out of arg via unwrap.

[-] maegul@lemmy.ml 1 points 2 years ago

Q6: Fixing

Of the following fixes (highlighted in yellow), which fix best satisfies these three criteria:

  • The fixed function passes the Rust compiler,
  • The fixed function preserves the intention of the original code, and
  • The fixed function does not introduce unnecessary inefficiencies
/// Gets the string out of an option if it exists,
/// returning a default otherwise
fn get_or_default(arg: &Option<String>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.unwrap();
    s.clone()
}

1:

fn get_or_default(arg: &Option<&str>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.unwrap();
    s.to_string()
}

2:

fn get_or_default(arg: &mut Option<String>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.as_mut().unwrap();
    s.clone()
}

3:

fn get_or_default(arg: Option<String>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.unwrap();
    s.clone()
}

4:

fn get_or_default(arg: &Option<String>) -> String {
    match arg {
        None => String::new(),
        Some(s) => s.clone()
    }
}

Answer

4

  • Really about best-practices here
  • 4 is a better, more idiomatic version of 3, especially because it requires ownership of arg which is restrictive and may not even be available
    • But I think 3 does fix the problem
  • 1 doesn't fix the problem
  • 2 ... I'm not sure about ... but I don't think having a mutable s helps with the problem either (?)

Context: The combination of is_none and unwrap here is a Rust anti-pattern, since a match combines the two functionalities and automatically deals with pushing the reference &Option into the interior to produce &String. Therefore the match solution is the most idiomatic, and passes the compiler without changing the intended type signature of the function.

The solution of changing &Option to Option is not desirable because it requires the caller to provide ownership of their option, which is a far more restrictive API.

[-] maegul@lemmy.ml 1 points 2 years ago

Q2

/// Makes a string to separate lines of text, 
/// returning a default if the provided string is blank
fn make_separator(user_str: &str) -> &str {
    if user_str == "" {
        let default = "=".repeat(10);
        &default
    } else {
        user_str
    }
}

Normally if you try to compile this function, the compiler returns the following error:

error[E0515]: cannot return reference to local variable `default`

 --> test.rs:6:9

  |

6 |         &default

  |         ^^^^^^^^ returns a reference to data owned by the current function

Assume that the compiler did NOT reject this function. Which (if any) of the following programs would (1) pass the compiler, and (2) possibly cause undefined behavior if executed? Check each program that satisfies both criteria, OR check "None of these programs" if none are satisfying.

  • None of these programs
// 1
let s = make_separator("");

// 2
let s = make_separator("");
println!("{s}");

// 3
println!("{}", make_separator("Hello world!"));

Answer

  • Slightly dodgy question, as the undefined behaviour first requires an empty string to be passed in to trigger the return of &default, which results in a dangling pointer being returned. Then, it's any program that uses the returned reference (so printing will do the trick)

Context: First, the caller must pass an empty string to trigger the problematic if-condition. This returns a dangling pointer. Second, the caller must use the result of make_separator, e.g. via println.

[-] maegul@lemmy.ml 1 points 2 years ago

Q5

  • Which programs would pass the compiler (presuming this function, from above, passes too) and possibly cause undefined behaviour?
/// Gets the string out of an option if it exists,
/// returning a default otherwise
fn get_or_default(arg: &Option<String>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.unwrap();
    s.clone()
}

Options:

  • None of these programs
// 1
let opt = Some(String::from("Rust"));
let s = get_or_default(&opt);
println!("{}", s);

// 2
let opt = Some(String::from("Rust"));
get_or_default(&opt);

// 3
let opt = Some(String::from("Rust"));
get_or_default(&opt);
println!("{:?}", opt);

Answer

  • All programs (1, 2 and 3).

  • Once arg.unwrap() occurs, s takes ownership of the underlying String.

  • Once s "dies", the String is deallocated.

  • But, opt, from before the call to get_or_default also owns the same String, and so once it "dies" and its memory is deallocated, a double-free will occur.

  • This actually threw me at first

  • My answer was program 3, as I figured that opt had to be used in some way for "undefined behaviour" to occur, as only then, did I figure, would the inappropriate memory be used resulting in an incorrect result

  • This is kinda wrong, though, because deallocation occurs once opt's lifetime ends, which will cause a double-free. println prolongs the lifetime while in program 2 the lifetime of opt clearly ends, I suppose, causing the double-free.

    • I personally think this is completely ambiguous, and unless I'm missing something, these undefined behaviour questions easily suffer from these problems.

[-] maegul@lemmy.ml 1 points 2 years ago

Q3: How fix

Of the following fixes (highlighted in yellow), which fix best satisfies these three criteria:

  • The fixed function passes the Rust compiler,
  • The fixed function preserves the intention of the original code, and
  • The fixed function does not introduce unnecessary inefficiencies

1:

fn make_separator(user_str: &str) -> &str {
    if user_str == "" {
        let default = "=".repeat(10);
        &default
    } else {
        &user_str
    }
}

2:

fn make_separator(user_str: String) -> String {
    if user_str == "" {
        let default = "=".repeat(10);
        default
    } else {
        user_str
    }
}

3:

fn make_separator(user_str: &str) -> String {
    if user_str == "" {
        let default = "=".repeat(10);
        default
    } else {
        user_str.to_string()        
    }
}

Answer

3

  • Return owned default
  • Convert user_str to a String to keep a consistent return type
  • Change return type to String
  • 2 is too restrictive in requiring use_str to be a String
  • 1 doesn't solve the problem
fn make_separator(user_str: &str) -> String {
    if user_str == "" {
        let default = "=".repeat(10);
        default
    } else {
        user_str.to_string()        
    }
}

Context: There is no valid way to return a pointer to a stack-allocated variable. The simple solution is therefore to change the return type to String and copy the input user_str into an owned string. However, requiring user_str to be a String would reduce the flexibility of the API, e.g. a caller could not call make_separator on a substring of a bigger string. It would also require callers to heap-allocate strings, e.g. they could not use a string literal like make_separator("Rust").

The most idiomatic solution to this problem uses a construct you haven't seen yet: Cow - Clone-on-write. The clone-on-write smart pointer would enable this function to return either an owned string or a string reference without a type error.

  • Interesting!!

[-] maegul@lemmy.ml 1 points 2 years ago

Q1

/// Makes a string to separate lines of text, 
/// returning a default if the provided string is blank
fn make_separator(user_str: &str) -> &str {
    if user_str == "" {
        let default = "=".repeat(10);
        &default
    } else {
        user_str
    }
}

When compiling, what's the best description of the compiler error?

  1. user_str does not live long enough
  2. function make_separator cannot return two different references
  3. function make_separator cannot return a reference of type &str
  4. cannot return reference to local variable default

Answer

Cannot return reference to a local variable

  • &default isn't allowed as default is local to the function.
    • What's the fix? Copy? Just return "=".repeat(10) directly?
    • How about just return an owned String (requires converting user_str to a String with to_string())

Context: Because default lives on the stack within make_separator, it will be deallocated once a call to make_separator ends. This leaves &default pointing to deallocated memory. Rust therefore complains that you cannot return a reference to a local variable.

this post was submitted on 21 Jun 2024
5 points (100.0% liked)

Learning Rust and Lemmy

460 readers
7 users here now

Welcome

A collaborative space for people to work together on learning Rust, learning about the Lemmy code base, discussing whatever confusions or difficulties we're having in these endeavours, and solving problems, including, hopefully, some contributions back to the Lemmy code base.

Rules TL;DR: Be nice, constructive, and focus on learning and working together on understanding Rust and Lemmy.

Running Projects

Policies and Purposes

  1. This is a place to learn and work together.
  2. Questions and curiosity is welcome and encouraged.
  3. This isn't a technical support community. Those with technical knowledge and experienced aren't obliged to help, though such is very welcome. This is closer to a library of study groups than stackoverflow. Though, forming a repository of useful information would be a good side effect.
  4. This isn't an issue tracker for Lemmy (or Rust) or a place for suggestions. Instead, it's where the nature of an issue, what possible solutions might exist and how they could be or were implemented can be discussed, or, where the means by which a particular suggestion could be implemented is discussed.

See also:

Rules

  1. Lemmy.ml rule 2 applies strongly: "Be respectful, even when disagreeing. Everyone should feel welcome" (see Dessalines's post). This is a constructive space.
  2. Don't demean, intimidate or do anything that isn't constructive and encouraging to anyone trying to learn or understand. People should feel free to ask questions, be curious, and fill their gaps knowledge and understanding.
  3. Posts and comments should be (more or less) within scope (on which see Policies and Purposes above).
  4. See the Lemmy Code of Conduct
  5. Where applicable, rules should be interpreted in light of the Policies and Purposes.

Relevant links and Related Communities

Thumbnail and banner generated by ChatGPT.

founded 2 years ago
MODERATORS
maegul@lemmy.ml
sorrybookbroke@sh.itjust.works
Jayjader@jlai.lu