What is the difference between dereferencing a raw pointer to a String and a raw pointer to an i32?

Question

fn func(s: *mut String, a: *mut i32) -> usize {
    println!("{}", unsafe { *s });
    println!("{}", unsafe { *a });

    unsafe { (*s).len() }
}

fn main() {
    let mut s = String::from("hello");
    let mut a = 10;

    func(&mut s, &mut a);
}

The above code fails with the error:

error[E0507]: cannot move out of dereference of raw pointer
 --> src/main.rs:2:29
  |
2 |     println!("{}", unsafe { *s });
  |                             ^^ cannot move out of dereference of raw pointer

Why does it happen for String and not for i32? Why is it complaining of a "move"?

Humbertohumble

Why is it complaining of a "move" — if you don't know what a "move" means in Rust, you probably shouldn't be using raw pointers yet. Go back and re-read the entire introductory book The Rust Programming Language – Tune

You could use std::ptr::read to copy out the raw string data, but that can easily result in undefined behaviour. – Telangiectasis

Answer 1

Why does it happen for String and not for i32?

The basic integral types (and in fact, many other types) in Rust implement the Copy trait. They have "copy semantics", not "move semantics". There is no change of ownership here... you're copying out the value. String does not implement the Copy trait and therefore this binding has "move semantics".

This is not unique to raw pointers nor does it have anything to do with their mutability. This example shows this can happen with immutable references:

fn func(s: &String, a: &i32) {
    let _x = *s;
    let _x = *a;
}

Why is it complaining of a "move"?

It does this because you're attempting to move ownership out of the unsafe block. As long as you're care-free about this then you need to contain the "move" within the unsafe block so the compiler just lets you shoot yourself in the foot. As such, if you restructure your code so as to not move outside of the unsafe block, the code will compile:

unsafe {
    println!("{}", *s);
}

Here it is running in the playground.

To re-iterate Shepmaster's point in the comment on your question though... if the term "move" sounds foreign to you then you should not be using raw pointers/unsafe blocks in the first place and should instead head back to the available documentation for Rust to understand the concept.. as it is a core one.

Bovid

So there is a transfer of ownership when calling println!() ? I mean why it works for ` let x = String::from ("hello"); println!("{}", x); println!("{}", x); ` . I am bit confused why the second println!() succeeds then? Also could you please elaborate on "It does this because you're attempting to move ownership out of the unsafe block". Please bear with my dumb questions – Humbertohumble

@Humbertohumble println! doesn't take ownership (in fact, it auto-references its arguments), but the value has to be moved from inside the block to outside. Here's an example of the same problem without any unsafe. The {} block forces a move by making the value *s into a temporary, just like the unsafe block did. println!("{}", *s); would work. (But so does println!("{}", s).) – Speechless

@trentcl, thanks! I am still quite not following it .What is the difference between unsafe { *s; } and unsafe { println!("{}", *s ); } – Humbertohumble

@Humbertohumble The difference is that println! auto-references its arguments, so there's an implicit & in front of the *s. The first Q&A I linked explains this. – Speechless

Thanks a lot trentcl! I think I get the gist now. Basically, the code let a = String::from("abc"); a; println("{}", a); triggers movement (transfer of ownership), resulting in error at println! as expected. So in the case of unsafe { *s; }, there is a movement to temporary (transfer of ownership again), just like the "abc" example above. Nothing more. I hope I have understood it correctly :) – Humbertohumble

Small correction. Rather than saying "there is a movement", I feel it is apt to say it rather does not allow the movement, considering the errors cannot move out of borrowed context or cannot move out of dereference of raw pointer – Humbertohumble