Rust pointers for C programmers

It’s true that &mut T is always unique; restrict says “this does not alias”, which &Ts trivially do. It goes on &mut T. For example, see https://github.com/rust-lang/rust/pull/31545, we had to remove this for a few releases due to an LLVM bug; it'll be back in the next release.

It’s phrased in the reference as

&mut T and &T follow LLVM’s scoped noalias model, except if the &T contains an UnsafeCell.

“noalias” is restrict here. But it’s not on &T, it’s the system as a whole that follows the guarantees, that is, both with and without.

You still can’t have un-exclusive access with a &mut T. For more: https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html

(And see the stuff on that page about how some of this is still in flux. And, maybe I’ve made some mistake with my words here; this stuff is hard and not what I deal with day to day...)

hsivonen3• 8 years ago

    Are *const T and *mut T also restrict in C terms? (If not, why not?)

steveklabnik19• 8 years ago

They are not. They’re not because they provide no guarantees; they’re just regular pointers.

cwzwarich3• 8 years ago

Actually, &mut isn't equivalent to restrict, since two restrict pointers are allowed to alias in C as long as none of the intervening accesses are writes.

steveklabnik19• 8 years ago

Isn’t that the same in Rust? For example, split_at_mut?

(I mean, it’s not like this is 100% nailed down yet...)

evmar2• 8 years ago

When I was learning Rust I leaned heavily on C-based analogies like this but I found they ultimately ended up being kinda harmful, because I was thinking (in C mode) "do I want to pass a pointer or a value to this function" rather than (in Rust mode) "do I pass ownership or a borrow to this function".

For an example of the difference, here's a function that consumes a 1kb buffer, returning the sum some of its contents. No pointers or references at all, everything "passed by value".

https://godbolt.org/g/icoVvz

To my C programmer's eye this looks wrong, but from the output you see there is no memcpy. (Edit: this is wrong, both C and Rust do memcpy, see below comments, but I think my point stands.)

I'd be shocked to see a C programmer write the equivalent code ("passing by value a big struct to a function"), while in Rust it's not only idiomatic to write that code but frequently also necessary, depending on whether the function wants to take ownership its argument or some of its contents. (Imagine a more complicated 'stuff' struct that contained embedded pointers to other things.)

I'm a little embarrassed to say I ended up looking at the output on rust.godbolt.org a lot to convince myself that the bits of code I was writing was "ok", which is something I never did when learning e.g. Haskell or Go. I think the reason here is that Rust feels so close to C that there's a bit of an uncanny valley effect, where you can mostly pretend it's C up until you hit a wall.

tom_• 8 years ago

In C the memcpy would be done by the caller.

Rusky7• 8 years ago

This is wrong. Passing a large struct by value does introduce a memcpy... in the caller: https://godbolt.org/g/26annS

The same is true in Rust, though it's trickier to show on godbolt because the equivalent of `extern` is less accessible in that context.

Rust programs often put those large structs in Boxes when they need to transfer ownership of something large, which is something straight out of "C mode."

evmar2• 8 years ago

Here it is on godbolt (using noinline): https://godbolt.org/g/7bskDc

The point I (poorly) was trying to make here was that passing things by value in Rust is fairly common, for e.g. Rc<T> or Option<T>, while in the C I've seen you basically never pass structs by value. But I guess, continuing the analogy, in C++ you do pass the equivalent of Rc<T> by value.

noncoml3• 8 years ago

You are absolutely right. The Rust book makes it sound like that passing structs is free, but it’s absolutely not. It’s always bit-wise copy. Relevant Reddit and Stackiverflow discussion with godbolt examples:

https://www.reddit.com/r/rust/comments/8ts6b4/is_anyone_else...

I felt a bit betrayed when I read them..

klodolph• 8 years ago

In C you should be equally cognizant of whether you are passing ownership or a borrowed reference. The difference is that this is not encoded in the type system. There are conventions revolving around function names that can encode this.

Animats• 8 years ago

That's when you borrow. You don't need to take ownership. You only need read access, so pass as a non-mutable reference.

Jweb_Guru5• 8 years ago

The simple answer here is that you cannot make a [T]. That actually makes perfect sense when you consider what that type means.

While this is true, I believe there's ongoing work to allow allocating [T] (and other dynamically sized types) on the stack under certain circumstances, using alloca. Which is quite nice since this was an area where Rust lagged behind C.

PeCaN• 8 years ago

Ada can do this conveniently and it can be nice for efficiency and embedded systems (which may not allow heap allocation). It would be nice to see the same feature in Rust.

wcrichton2• 8 years ago

Another important detail around pointers in Rust: it's common for "smart pointers" like reference counting (std::rc::Rc in Rust, std::shared_ptr in C++) and even boxes to be structs that contain pointers plus other information (like a reference count).

However, for ergonomic reasons, Rust wants you to be able to use a Box<T> or Rc<T> in the same way you would a &T, i.e. dereferencing with *t returns the underlying value in every case. Therefore, Rust allows you to overload the dereference operator with the Deref trait, e.g. the implementation of Box [0] does a double dereference to access the inner struct member.

Note that this is distinct from "auto-deref" (or deref coercion), another Rust feature that will automatically dereference pointers as necessary in certain cases, like calling a method on a struct (so there is no arrow operator "->" in Rust like in C++). See the Book [1] for more details.

[0] https://doc.rust-lang.org/src/alloc/boxed.rs.html#536-542

[1] https://doc.rust-lang.org/book/second-edition/ch15-02-deref....

Diggsey• 8 years ago

That's not quite true: the reference counts for `Rc` and `shared_ptr` are not stored adjacent to the pointer. In rust these types are guaranteed to be pointer-sized (when the target is Sized) or fat-pointer-sized otherwise.

The reference counts are necessarily stored on the heap at the target of the pointer (the reference count must be shared between all the pointers) pseudocode:

    struct RcBox<T> {
        strong_count: usize,
        weak_count: usize,
        value: MaybeInit<T>,
    }

Additionally, when you use `into_raw`/`from_raw` you're actually getting a pointer to the value member of the `RcBox` struct (ie. the reference count is stored at a negative offset from that pointer).

wcrichton2• 8 years ago

Sure, agreed that they aren't literally adjacent in the struct. My broader point is just that there's a level of indirection which is abstracted over by the Deref trait.

saghm• 8 years ago

Note that this is distinct from "auto-deref" (or deref coercion), another Rust feature that will automatically dereference pointers as necessary in certain cases, like calling a method on a struct (so there is no arrow operator "->" in Rust like in C++).

Is this actually distinct? The docs for the reference type explicitly says that &T implements Deref for T, so it seems like it's the exact same thing to me.

See https://doc.rust-lang.org/std/primitive.reference.html

steveklabnik19• 8 years ago

Is this actually distinct?

One is "overload star", the other is "automatically insert & and star", if I'm understanding the distinction that your parent is making.

Koshkin• 8 years ago

Sometimes I have a feeling that there is something wrong with the world in which the tools are much more complex than the things you make with them. (This not always has been the case; these days the signs of over-engineering and over-design are everywhere.)

clarry• 8 years ago

https://www.cottandco.com/media/lot/4dca69f31a861dcf7c51fd07...

https://mfg230cls.groups.et.byu.net/projects_and_labs/images...

eberkund• 8 years ago

The tools being complex are what allow the products of those tools to be simple.

kybernetikos• 8 years ago

It's sort of the opposite. If something is very simple, it's likely it is simple because you're standing on top of a massive tower of complexity and not worrying about it.

Rust is complex because it makes you worry about a bunch of stuff that other languages allow you to forget. But this also means that it allows you the control to create simpler things than can be created with the tools that make you feel like everything is simple.

dochtman• 8 years ago

I'm not sure why the distinction for Box between a pointer and a struct with a single pointer in it matters. For all intents and purposes, aren't they the same thing?

steveklabnik19• 8 years ago

At the binary level, yes, they're the same thing: a struct with one member is the same as just the member.

However, in the end, it's all just binary: that doesn't mean that using different phrasing doesn't help understanding. If it helps it make sense to the OP I'm all for it.

brian-armstrong6• 8 years ago

I really want to like Rust, but coming from C++, the language just feels incomplete. There’s a lot you should be able to do safely but the compiler just isn’t there yet to figure it out. I was surprised to find you can’t safely pass ownership of a Box through a channel for example (that is, Box doesn’t implement Send).

I’m also not a fan of the crazy chained functions everywhere, and making ? do an implicit return makes it hard to visually scan code for control flow.

I’m hoping Rust matures into a better language. For now I think C++ is still far more productive and ergonomic, and there are ways of making it safe too.

Rusky7• 8 years ago

Box totally implements Send: https://doc.rust-lang.org/std/boxed/struct.Box.html#syntheti...

Also I'm not sure how ? obscures control flow to the same level as C++, which propagates exceptions with no syntactic marker at all.

brian-armstrong6• 8 years ago

Well to be fair, I would never advocate using exceptions.

Also I’m quite sure Box doesn’t. I’ve seen compiler errors when attempting to pass one via mpsc.

sacado2• 8 years ago

I preferred the "try!" syntax. The ? is harder to parse visually, harder to find, and makes the language a little more complex (that's one more operator, one more thing to understand, one more thing to parse for tools, etc.)

psyclobe2• 8 years ago

Hope Rust runs on Solaris, for Josef's sake at least lol.

steveklabnik19• 8 years ago

It’s tier 2 https://forge.rust-lang.org/platform-support.html

Rust pointers for C programmers

Related Stories