Unstable compilers

Posted Sep 25, 2024 9:52 UTC (Wed) by pbonzini (subscriber, #60935)
In reply to: Unstable compilers by Wol
Parent article: Committing to Rust in the kernel

> it appears the Rust devs seem much more amenable to treating "you're optimising away necessary code" as a bug than the C folks were.

The optimization backend in the end is the same, the difference is that the language itself is designed to make it harder to trigger undefined behavior.

For example the level of aliasing is declared explicitly by separating shared and exclusive references (& and &mut). Developers can only turn a shared reference into an exclusive one via UnsafeCell (and then the code needs to be explicitly marked as unsafe) or wrappers thereof (which are carefully designed to avoid undefined behavior).

to post comments

Unstable compilers

Posted Sep 25, 2024 10:42 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

> > it appears the Rust devs seem much more amenable to treating "you're optimising away necessary code" as a bug than the C folks were.

> The optimization backend in the end is the same, the difference is that the language itself is designed to make it harder to trigger undefined behavior.

Maybe that's the effect. But even today the C devs seem keen on creating new undefined behaviours. In Rust, undefined behaviour is viewed as a bug in the language (or as "you can only do that in an unsafe block") as far as I can tell. Completely diametric views on UB.

Cheers,
Wol

Unstable compilers

Posted Sep 25, 2024 18:10 UTC (Wed) by sunshowers (guest, #170655) [Link]

Yes, that is correct, and Rust is better for it. Under the assumption that unsafe code is correct, safe code doesn't have UB.

I would rather optimization 'alpha' be extracted through principled approaches like enabling the use of "restrict" on &mut pointers.

Unstable compilers

Posted Sep 26, 2024 20:04 UTC (Thu) by ralfj (subscriber, #172874) [Link]

> In Rust, undefined behaviour is viewed as a bug in the language (or as "you can only do that in an unsafe block") as far as I can tell. Completely diametric views on UB.

Yes -- mostly the latter. I think Undefined Behavior is a great tool for language designers; they can use it to enable powerusers to get the compiler to do things you'd never (well, not practically) get it to do without. But it is the language designer's responsibility to yield this tool with care.

A more lengthy discussion of this point is in my blog: https://www.ralfj.de/blog/2021/11/18/ub-good-idea.html

In C, things can be UB either because the standard says they are UB, or because the standard is entirely silent about that case. The latter is considered a spec bug in Rust, it is not acceptable for us to have things be "implicitly" UB. The former still happens, but we are doing our best to describe those cases as unambiguously as possible. Rust doesn't have a spec yet, so we still have a lot of work ahead of us, but Miri [1] helps a lot: if we understand our UB rules well enough to wire them into a tool that can automatically test for UB, that's a great first step towards an unambiguous specification! I think something like Miri would be nearly impossible to do for C, since the standard is just not sufficiently clear about many corner cases.

[1]: https://github.com/rust-lang/miri/