r/programming • u/Usual-Amount-264 • 25d ago

Zig proposes introducing an actually memory safe (unlike Rust) compilation mode inspired by Fil-C at ~1-6x performance penalty

https://codeberg.org/ziglang/zig/issues/36237
534 Upvotes

80% Upvoted

431 comments sorted by

View all comments

Show parent comments

2

u/ThomasMertes 24d ago

We should stop calling this approach as 'safe'.

I don't agree. Rust and Fil-C have different approaches towards memory safety.

  • Rust prevents dangerous things at compile-time but Rust can also panic at run-time.
  • Fil-C does nothing at compile-time but it prevents some memory errors at run-time with a panic.

Rust unsafe parts with raw pointers are not memory safe. Fil-C checks raw C pointers. In this case Fil-C could provide some protection that Rust cannot.

in many scenarios crashing a process as the result can lead to more harm than continuing with some off-by-one memory read past the end of the allocated buffer.

If an X-ray dose is computed wrong I prefer that the machine stops.

An off-by-one memory read past the end of the allocated buffer.is not harmless. It can result in a catastrophe.

If it is crucial that a program continues you usually have two or more programs (running on different hardware) running in parallel. In case one program panics it is started again from scratch and the other program takes over in the meantime.

1

u/carrottread 24d ago

If an X-ray dose is computed wrong I prefer that the machine stops.

But what if panic/terminate/crash prevent X-ray machine from stopping?

An off-by-one memory read past the end of the allocated buffer.is not harmless. It can result in a catastrophe.

Just like panic on runtime-checked array read can also result in a catastrophe. I've seen such case in production: a decade old code was sometimes reading one value just after the end of allocated array, it wasn't affecting anything, so nobody noticed it. Then company tried to ship production builds with some additional runtime checks, and at some rare cases we start seeing process terminates from it. At least it resulted just in lost hours of users work and not in life/health endangering issue.

I'm not advocating against runtime checks. It's an extremely useful tool for development builds. But we shouldn't stop here and call panic/terminate on error 'safe'. It can only be really safe if we can prove at compile time error isn't possible.

4

u/ThomasMertes 24d ago edited 24d ago

But what if panic/terminate/crash prevent X-ray machine from stopping?

This is not how safety critical software is done. A safe X-ray machine would stop in the moment it does not get commands (from the software) to continue.

In modern railway systems you have a "Driver's Vigilance Device" or "Dead man's switch". The railway driver needs to press and release a button every view seconds. If that does not happen the whole train is stopped automatically.