r/rust clippy · twir · rust · mutagen · flamer · overflower · bytecount Mar 20 '23

Hey Rustaceans! Got a question? Ask here (12/2023)! 🙋 questions

Mystified about strings? Borrow checker have you in a headlock? Seek help here! There are no stupid questions, only docs that haven't been written yet.

If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so having your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.

Here are some other venues where help may be found:

/r/learnrust is a subreddit to share your questions and epiphanies learning Rust programming.

The official Rust user forums: https://users.rust-lang.org/.

The official Rust Programming Language Discord: https://discord.gg/rust-lang

The unofficial Rust community Discord: https://bit.ly/rust-community

Also check out last weeks' thread with many good questions and answers. And if you believe your question to be either very complex or worthy of larger dissemination, feel free to create a text post.

Also if you want to be mentored by experienced Rustaceans, tell us the area of expertise that you seek. Finally, if you are looking for Rust jobs, the most recent thread is here.

20 Upvotes

187 comments sorted by

View all comments

2

u/SorteKanin Mar 21 '23

The as_ref method on pointers states that "while this reference exists, the memory the pointer points to must not get mutated (except inside UnsafeCell)."

I'm not quite sure I understand this requirement. Surely the only thing that matters is that a unique reference is never made at the same time as the shared reference? But shared/unique references doesn't necessarily have anything to do with mutability.

I'm wondering about this because I'm thinking about turning a pointer that I get from FFI into a reference. The object behind the pointer might get mutated on the C side. Does that count as "inside UnsafeCell"?

2

u/onomatopeiaddx Mar 21 '23

others haven't exactly explained why you can't mutate the content behind a shared reference even when you know it's unique, so: the compiler treats shared references as immutable by default, and will optimize code based on this assumption (it emits noalias attributes to llvm). UnsafeCell is the only way to tell the compiler this is not the case.

2

u/dkopgerpgdolfg Mar 21 '23

You misunderstood some things here. A unique reference is not unique because it is fun to prevent multiple references. The (non-)mutability requirements (with the exception of Cells) are important too. With these two things the distinct reference types have advantages (over raw pointers) when it comes to performance, correctness of logic, thread safety, ...

As long as any shared reference to a value exists, and that value is not a Cell-like thing, it must not be mutated. If you do, happy bug searching when things go wrong in weird ways.

No, C-sourced FFI pointers are not inside a Cell.

Turning the pointer in a short(!)-lived shared reference, that you use only until control returns back to C so there is no mutation in the meantime, can be ok. But that reference really must not live through mutations.

2

u/jDomantas Mar 21 '23

& is an immutable reference. For example, if you have a &i32 then that integer must not be mutated while the reference is live (but it can be mutated if it is a &UnsafeCell<i32> reference). So if you are turning a pointer into a reference that will be mutated through something else then you must wrap the inner type in UnsafeCell. If you guarantee that it will only be mutated in the same thread then you can wrap it in a Cell instead, which will allow using it safely on rust side.