3 ms·

I believe it's about creating a set of rules that when followed allow people to write `unsafe` code safely. It sounds like currently if you write `unsafe` code,

I believe it's about creating a set of rules that when followed allow people to write `unsafe` code safely. It sounds like currently if you write `unsafe` code, the optimizer could introduce undefined behavior. This paper is creating a set of rules so that if your `unsafe` code follows those rules, there won't be undefined behavior.

cyphar 7y ago
No, that's not quite right. Unsafe code written today does not by default have undefined behaviour -- if it did, it would be a useless tool. You can write programs using unsafe that have undefined behaviour (of course) but that's a bug in the code written. This paper isn't about that (nor is it necessarily about unsafe Rust). It's about compiler optimisations. Because Rust has very clear rules about references and borrows, the idea is to come up with a model for Rust code that allows for a particular optimisation (namely, to allow telling the compiler that two pointers do not alias -- do not refer to the same memory). Obviously unsafe code would need to make sure it obeys this new memory model, otherwise the code would be invoking undefined behaviour.