Repercussions for potential future C flags?

Posted Apr 26, 2023 8:39 UTC (Wed) by matthias (subscriber, #94967)
In reply to: Repercussions for potential future C flags? by tialaramex
Parent article: An update on the GCC frontend for Rust

> Merely creating a mutable alias (e.g. int foo = 1; int *bar = &foo; in C) is forbidden in Rust.

Fortunately, the borrow checker will prevent creating aliases to mutable references, even when you are using unsafe rust. In unsafe rust you will usually deal with raw pointers. And it is perfectly valid to have aliasing raw pointers as long as you take care of data races. Thus you basically have to uphold the same invariants as in unsafe C. [*]

Of course, at the boundary to safe code you have to ensure that you only create one mutable reference from your raw pointer, but that should be easy to comply with. And you are not allowed to mutate the state through your raw pointer while there exist any references (mutable or shared). So, it should not be that hard after all to create correct unsafe rust code. And -- as you said -- you will rarely need it at all and you can therefore be extra cautious at the places where you really need this.

[*] There is no such thing as safe C ;)

Repercussions for potential future C flags?

Posted May 3, 2023 11:13 UTC (Wed) by ssokolow (guest, #94568) [Link]

Not quite. There are ways to synthesize aliasing pointers from raw pointers in unsafe Rust which are UB that the optimizer may recognize but the type-checker can't catch.

As Aria Beingessner has written about in Rust's Unsafe Pointer Types Need An Overhaul, there definitely is improvement to be done.

I've seen at least one talk demonstrating examples of how stuff like that in unsafe Rust can be a footgun because there's an intuitively obvious way to do something, but it results in something like "casting through a reference" and, thus, invokes undefined behaviour. (With the proper solution being to use some function under std::ptr to manipulate the raw pointer directly.)