Answer of a Question from last Quiz in 4.1 is Incorrect

[Wajishahid10]

I was skeptical about the answer as per the concepts I read in the book so I compiled and ran the answer which should run according to the answer.

[dullbenz]

I think you misunderstood the question. The description already says that all of the snippets are rejected by the compiler. When this question is looking for are whether you understand why the compilter stops you from doing certain things.

Examples of undefined behaviour stopped by rust (both compiler and runtime)

• Accessing an element from an array with an index that's out of bounds -> this will normally cause a panic at runtime (rust stops this). If the runtime didn't stop this, it will cause undefined behaviour because it will try to read from that location and basically anything may be stored there as it wasn't part of the array's allocation i.e undefined behaviour
• Accessing memory from the heap that has been freed, for the same reasons as above will cause undefined behaviour but luckily this will not occur because it is stopped by compiler.
• Double freeing of memory from the heap will cause undefined behaviour as well because if the memory was already freed, then something else may have been written to that location and freeing it again then causes undefined behaviour as the program doesn't know how that data was being used.

So in the case of this question, first we need to assume that the compiler did not reject the code and allowed it to run (As all of the snippets will be rejected. They mention some tools earlier in the book which can be used to simulate such programs but I haven't tryed those yet, but if inquisitive, you can check them out. I will probably be doing so further along).

Now which of the programs cause undefined behaviour when allowed to run.

This causes undefined behaviour because of a double free

TL;DR
This occurs because b is moved into b2 and b is moved into the function move_a_box again (Rustc will normally stop you here but in this case we assume it didn't). So what happens when the program runs is that, the heap memory location is first freed when the function move_a_box completes and it's variable, x (b as given in the already question) is removed from the stack and since it owns a pointer to the heap, that location is also freed. Now when the main function completes, it removes b2 from the stack and it also owns a pointer to the heap and so it has to free that location. But then this would have been the same memory location already cleared by the move_a_box function before.

This doesn't cause undefined behaviour because even though b is moved into b2, the program location that b points to still exists as it hasn't been cleared yet. So reading from it would still be technically okay at this point (even though it would normally be blocked by the compiler). And the later call to move_a_box passing b2 is equally not a problem as it moved the right variable b2 and not b which had already been moved. Note that the println macro doesn't move b even though it seems to pass b directly into the function. This is because of coersion as it automatically transforms b to &b based on it's signature. Don't know how this works completely yet, but I guess I will once I progress to later chapters

This also causes undefined behaviour for the same reasons as the first one. basically they've just changed interchanged the positions of the call to the function and the variable reassignment.

For this last one, you may then think it's similar to the second i.e the value is moved and the a read is attempted on it. But there's a slight difference here. In this case, the variable is moved by a function call and as such when the function completes as is the case when it goes to the next line, the heap memory location would have been freed. And so trying to access freed memory is undefined behaviour as it could contain anything, heck! even data from another program.

To summarize,

• A double move of the same variable will always cause undefined behaviour as it will always eventually lead to a double free (Case 2 and 3). Note let b2 = b; let b3 = b2; is not a double move but let b2 = b; let b3 = b is a double move i.e thesame variable moved more than once
• Accessing memory that has been freed will always cause undefined behaviour as well

[wudl-21]

hi @dullbenz, thanks for the detailed reply, however I still have one point unclear about the answer:

This doesn't cause undefined behaviour because even though b is moved into b2, the program location that b points to still exists as it hasn't been cleared yet.

It's true that the heap memory hasn't been freed yet, but after the move, b is marked as uninitialized and its stack slot can be reused or overwritten by the compiler at any time. Accessing b in println! reads from an uninitialized binding, which is undefined behavior regardless of whether the heap data still exists.

[dullbenz]

@wudl-21 I think you can look at it this way (I may be wrong):-

TL;DR
With behaviour that is assumed to pass the compiler even though it doesn't, there are some assumptions I make to ease my understanding. There are several reasons behind the move concept.

• when passing a variable that is a mutable reference (Since mutable references must be unique, so it can only be moved, not copied)(uniqueness of a mutable reference prevents race conditions on the data concurrent RW on the same data)
• when passing a variable that owns heap data (Since only one variable can own heap memory, it can only be moved, not copied).

Now, we need to be able to make some distinctions between compile-time and run-time. The compiler does a lot of work, so that the run-time just has to focus on running the program. Now, most of the features (if not all) involving borrowing and the borrow checker are compile-time features and are not enforced at run-time and frankly, rightfully (If the compiler can assert that the code is safe, the run-time believes it and just runs it.)

What this means for a phrase like "Assume the code passes the compiler" in the case of moving a variable and then still accessing it.

First of all, think about what happens in a language like JS if you say let b = a . If a is an object and thus a reference, it simply copies the same reference into b, and so modifying the properties of b changes a as well. The same thing happens in Rust at run-time, just that the compiler takes measures to prevent this from happening before it ever gets to run, i.e move and borrow concepts. It always moves the variable unless the Copy trait (At run time, everything is always copied, but the Copy trait explicitly informs the compiler that this variable is safe to be copied).

Now your statement below is correct

It's true that the heap memory hasn't been freed yet, but after the move, b is marked as uninitialized, and its stack slot can be reused or overwritten by the compiler at any time. Accessing b in println! reads from an uninitialized binding, which is undefined behaviour regardless of whether the heap data still exists.

But the marking is at compile time. If allowed to run, that marking simply doesn't exist. The run-time only really uninitialises the stack variable (and also frees any owned heap memory) when the enclosing function exits. And so technically the variables still exist and can be accessed until they are reinitialised with a value. Rust simply prevents this from happening at compile time

Short Version
When you want to assume code passes the compiler and gets to run, the concept of moving goes out the window (everything is always copied, so all assignments work as if the type implemented the Copy trait). So after the supposed move, both variables still exist until they are deallocated from the stack when the function exits. The Rust compiler simply prevents the code you write from accessing it after it has been supposedly moved.

[bradleysmith]

I don't understand the explanation. All 4 code snippets are trying to do something with a moved value at some point. What makes calling println on a moved b any less UB than passing a moved b to move_a_box, or assigning it to b2?

[dullbenz]

I don't know if this explanation will be clearer, but here it goes.

First, let me start with this. The concept of move is primarily a compile-time guarantee.

What does this mean?

Consider the code snippet below (I used object here to mimic JavaScript, as strings in JavaScript are not natively pointer-like)

let mut var1 = Box::new(Point {x: 1, y: 2}); // Assuming the struct Point has been defined prior 
// In js, the above would be:- let var1 = { x: 1, y: 2 };

let var2 = var1;
// At run-time behaviour of JS and Rust here would be similar
// i.e copy the reference contained in var1 into var2
// So doing something like below 
var2.x = 0; // affects var1.x as well in both languages

// Now the difference: **Compile Time**
println!("{}", var1.x); // Note that the println! Macro never moves the variable
// even though I passed the variable without the borrow syntax, it coerces it into a borrow, i.e equivalent to println!("{}", &var1.x)

// The above line will not pass the Rust compiler because the compiler marked the `var1` variable as moved
// and so cannot be accessed. Note that this is just a compile-time marking, and if left to run
// at run-time will print `0` just as will happen in JS. (No undefined behaviour)

// Now if I do this
let var3 = var1; // This will also not pass the compiler,
// But if allowed to run (i.e compiled without safety checks), then it will also copy the reference contained in `var1` into `var3`
// Just as will happen in JS. 
// But the difference with JS will occur when the function exits.
// In JS, there's a garbage collector that runs and frees memory in the heap when no references to it exist.
// In Rust, there is no garbage collector and heap memory is freed when its owning variable goes out of scope
// So in Rust, since var2 and var3 both own (or think they own, since var1 was moved into both of them) the same heap data,
// that same memory location will be freed twice. This is undefined behaviour because, when it's freed the first time, 
// Any other process may have copied data into that location, and the second free could potentially free memory, which
// it wasn't supposed to, and cause unknown behaviours and/or errors (hence undefined behaviour)

That's why, in a nutshell, whenever there's a double move, it implies a double free, which implies undefined behaviour