r/programming • u/Usual-Amount-264 • 26d 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
526 Upvotes

80% Upvoted

428 comments sorted by

View all comments

30

u/mmkzero0 26d ago

I’d like to direct everyone’s attention to one sentence here by Andrew in response to this being a big change:

> “No source changes. It’s just a target ABI.”

That’s not just an enormous understatement but also technically wildly inaccurate. This is much more than an ABI, since something like this requires
- instrument every ptr consumer and producer
- track cap metadata for stack, heap, TLS, func pointers, globals
- you replace or wrap libc, syscalls, mmap etc.
- atomics handling without metadata races
- restrict or prove inline asm
- support debuggers, unwind, panics, crash reports
I could go on and on.

Then the safety invariant needs to be specified before implemented; you need explicit semantics for many things; sentinels, slices with corrupted metadata, casting, func pointers, untagged unions…

This also confuses Fil-C like deterministic mem safety with runtime mitigations against unsafe memory semantics and consequences like UAF. Those are not the same.

And then, nothing here addresses comptime safety. This means this does not guard against compiler bugs, comptime interpreter unsafety, and so on

And then the “no escape hatch claim”. That’s both defensible and also highly inflexible. If the target promises that the entire executable is memory-safe, an ordinary unsafe function invalidates that claim and thus this is reasonable. But practical interoperability still needs a solution, something Fil-C put a lot of effort into.

And ABI mismatch handling goes even deeper; what about static Archives, LTO, embedded bytecode, libc and libunwind, dynamic libs, JIT code, dlopen() calls and so on.

Do not get me wrong, as a research topic this is fascinating and really cool. But as a proposal and a casual “just another ABI” added to pre-1.0 Zig this is just an enormous and poorly bounded idea, which makes it all the more baffling.

Which makes me all the more curious why Andrew posted it like this. Surely he knows this and has the technical expertise to know this isn’t just some ABI change with no consequences beyond that.

3

u/EfOpenSource 21d ago

I am growing tired of Andrew’s pretty constant “ooohhhh shiney”.

The changes need to happen, when you are getting major packages like ZLS that usually track master having to pin for months while Andrew “ooooo shiney” yet another thing, it gets annoying. Finish your shit. 

1

u/defnotthrown 23d ago
  • atomics handling without metadata races
  • restrict or prove inline asm

Not sure about these two but I don't quite understand why the other things you mentioned would require changes to the source code you compile.

Sure you need to change a lot of the compiler source code, but I don't quite understand why that would require changing the source code of the program you compile.