Unstable compilers

Posted Sep 25, 2024 9:32 UTC (Wed) by sam_c (subscriber, #139836)
In reply to: Unstable compilers by admalledd
Parent article: Committing to Rust in the kernel

Thanks. I guess I'd make the distinction between new features only available in and bugginess though.

Unstable compilers

Posted Sep 25, 2024 9:46 UTC (Wed) by Wol (subscriber, #4433) [Link] (4 responses)

> I guess I'd make the distinction between new features only available in and bugginess though.

You need to add to that list "new features either enabled by default, or often enabled by force, that break the kernel".

One only has to look at all the complaints about UB, where gcc was optimising code away. Quite often (a) this stuff was NEEDED, and (b) there was no flag to disable the optimisation responsible for removing them.

So the compiler wasn't buggy, it was working as designed. And if the die-hards are going to complain and say "well Rust needs to call C to access the hardware", it was not at all unusual for C to have to call assembler to access the hardware, because the C compiler was just deleting the code as UB with no way to stop it. Hence my comments in various places about mathematics is not reality.

The difference is, 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.

Cheers,
Wol

Unstable compilers

Posted Sep 25, 2024 9:52 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (3 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.

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).

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/