>The program terminates, which may be highly undesirable, or even unacceptable, creating other safety issues if the software is vital for operating critical infrastructure

I'm no rust evangelist but I don't understand this point. In what scenario would you rather have an out of bounds read go through and let Jesus take the wheel rather than print a stacktrace and have a clean-ish exit?

You wouldn't. You cut off the rest of that sentence in your quote, the full sentence is

> The program terminates, which may be highly undesirable, or even unacceptable, creating other safety issues if the software is vital for operating critical infrastructure, but the run-time checks ensure the program will never execute unsafe code that would result in undefined behaviour.

That said, this whole sentence here just feels kind of out of place, like it was written just for the sake of having something to say about a panic.

In those kinds of scenarios I think you'd typically want to go for formal verification or similar methods because you want liveness guarantees in addition to memory safety guarantees.

Formal verification doesn't mean shit when a cosmic ray bitflips your program counter.

Safety critical systems need to fail safely, because they will fail. Detecting unexpected execution should halt the system and revert it back to a known state (e.g. cycle power).

Depends on the "threat model" I suppose, for lack of a better phrase. I'd imagine hardware faults and the response(s) can be modeled if you decide to do so as well.

Force the program to be written in a way to handle them? There ought to be a lint that says, no unwraps. Unfortunately, the stdlib is designed for "common use", not "highly critical infrastructure".

> There ought to be a lint that says, no unwraps.

I think this is it:

https://rust-lang.github.io/rust-clippy/master/index.html#un...

One safety critical project I worked on used null pointer accesses to do control flow. So, that one.

I don’t know Rust, but I would think/hope you could wrap those control flow calls in some way, so those particular null pointer accesses do what you want, but other accidental ones are caught and safely handled (e.g. resetting the system to a safe state.)

You could, but a better strategy for that particular project would have been to rewrite it to not need that.