The key thing that memory safety provides is local reasoning. You can look at some important piece of code and conclude that it does the right thing, even if there are a million other lines of code somewhere else. UB makes this impossible; no matter how carefully you review dont_launch_missiles() it might launch the missiles due to an integer overflow in totally unrelated code in the same process.
I agree with you, but this feels more of "fixing" inherently unsafe code in the same way we "fixed" the elephant's foot in Chernobyl by covering it with a giant roof. It doesn't actually fix the problem, just lessens and prolongs it.
Yes the resemblance to the sarcophagus is I suppose warranted. The best of bad options.
The assumption in Fil-C is that you can't or won't rewrite. So a modified C compiler which rejects the uninitialized variable (as Rust would) is not acceptable because now what? We were supposed to make the existing C program memory safe, not reject it, anybody could write a "compiler" which rejects the C programs as unsafe.
This is the same assumption C++ had. C++ 26 lands "Erroneous Behaviour" for this purpose. Previously if you write `int x; foo(x);` that's Undefined Behaviour in C++ just like C, game over, anything might happen if this executes.
In C++ 26 `int x; foo(x);` is Erroneous but not Undefined. It might tell you (perhaps at runtime) that you forgot to initialize x, because doing so is an error - but if it presses on it will behave like `int x = SOMETHING; foo(x)` where SOMETHING was chosen by your compiler and implemented exactly the way you'd expect, by quietly initializing your uninitialized variable.
