3 ms·
It's only impossible in safe code. Unsafe cade can violate those rules all day long. You can't guarantee that there's no unsafe code running concurrently.
by Retra 10y ago
It's only impossible in safe code. Unsafe cade can violate those rules all day long. You can't guarantee that there's no unsafe code running concurrently.
- kzrdude 10y agoAny use of `unsafe` that breaks unrelated safe code is broken and buggy; if that scenario would happen like you describe it, the code is breaking Rust's aliasing rules: that's possible using `unsafe` but invalid and leads to UB.
- Retra 10y agoI'm not talking about 'uses of unsafe', I'm talking about code that is unsafe. Much of that code is not even written in Rust, so there's no 'unsafe' to use.
- kzrdude 10y agoOk, so code that is memory unsafe (broken!). One must still say "unsafe" to bring it into Rust (to use ffi, or make a safe wrapper); so there is still a clear location in the Rust code that is to blame.
- cynicalkane 10y agoConcurrently modifying aliased memory (`&` references and pointers) is undefined behavior. Not just in Rust, but in just about any language. As an aside, alias unsafety in Rust is always UB, even without concurrency.
- deleted 10y ago[deleted]