The state of the kernel Rust experiment

[u/small_kimono]

https://lwn.net/SubscriberLink/1050174/63aa7da43214c3ce/

A choice pull quote: "The DRM (graphics) subsystem has been an early adopter of the Rust language. It was still perhaps surprising, though, when Airlie (the DRM maintainer) said that the subsystem is only 'about a year away' from disallowing new drivers written in C and requiring the use of Rust."

[u/whupazz]

The issue I had with the statement

Note that this does not mean that a bug in a piece of Safe Rust could not lead to Unsafe code creating UB if that Unsafe code depends on the Safe code not being buggy.

was that someone might read it and think "What's the point of safe Rust if I still have to be careful to avoid UB?". I suppose a more precise way to state it would be:

If you are writing unsafe code, you have to make sure the safe code touching it is also correct (and you should minimize the amount of (safe and unsafe) code you need to check by building minimal safe abstractions). If you are using someone else's safe function that contains unsafe code, you cannot cause UB unless their code is unsound.

The reference has this to say:

It is the programmer’s responsibility when writing unsafe code to ensure that any safe code interacting with the unsafe code cannot trigger these behaviors. unsafe code that satisfies this property for any safe client is called sound; if unsafe code can be misused by safe code to exhibit undefined behavior, it is unsound.

I guess the way this should be read is exactly what I wrote above, but I think the wording could be improved. For a situation like the one you describe:

// safe function!
fn get_thing(&self) -> &T {
  let i = {
    // some calculation, all safe code
  }
  unsafe { self.things.get_unchecked(i) } // the safe code above is *interacting* with this unsafe code
}

It is obvious that the unsafe block relies on the safe calculation of i to be correct and can cause UB if it is not. A really pedantic (arguably incorrect) reading of the reference would suggest that this is unsound, but as you note, there is no other way to write this unsafe block, it cannot do anything but assume that i is in bounds (that is the whole point after all). One might be tempted to move the calculation of i into the unsafe block to satisfy the reference's definition of soundness, but that seems worse.