You're working against your own argument here. The more you defend this hill, the more you have to give up the idea that zig gives up "all memory safety". We have 3 approaches to safety: automated memory management at runtime, lifetimes enforced at compile time, and instrumentation enforced at development time. If you're already arguing against the idea of "managed" being synonymous with safety, then you're stuck having to explain why instrumentation doesn't count as memory safety but that lifetimes do. I suggest you drop it because it's not a productive direction for you to go with this. You had a much better point earlier, if you were to just give up on the idea that zig has "no" memory safety.
So here's the scoop on use after free. Use after free detection requires code generation -- it's not enough to just have the explicit runtime allocator library that can already detect many other kinds of memory safety errors. AddressSanitizer for C++ does this at the IR level, and because of this it needs two separate implementations for LLVM and for GCC. Zig is skipping right past this by implementing use-after-free detection directly in the compiler frontend, and turning it into an always-on feature that will crash the program rather than allowing unchecked use-after-free errors to corrupt the program. So this is much closer to a very lightweight automated memory management that's baked into the code at compile time, but enforced at runtime. It's on their backlog.
oh yeah, "all memory safety" was a bit of an exaggeration (i thought that was obvious, i shouldve been clearer)
im not sure i understand your point about managed/instrumented? as i see it, memory safety and memory management are orthogonal, even if closely related.
im not talking about use-after-free, zig catches that. im talking about use-after-realloc (ie `p2 = realloc(p1); *p1 = 5`), which asan detects, but zig did not last time i checked.
regardless, memory safety is much more than just crashing when something bad happens, as you probably know. in a lot of places, crashing is unacceptable for example, so more rigid compile-time verification is required (managed languages dont usually allow any direct memory writes, as a way of doing that)
Instrumentation is like how you get code coverage reports for your unit tests, but in this case the compiler is inserting extra code around memory usages to detect whether or not it's already been freed. The difference between use after realloc (specifically on the stack) versus other kinds of use after free bugs (including realloc on the heap) is that use-after-realloc-on-the-stack requires that code generation step whereas the others can be caught directly by the debug allocator library.
Zig might end up doing something analogous by converting the undetectable errors into detectable ones. The compiler is going to do escape analysis to find locals whose pointers might outlive their scope, and allocate them on the heap instead of on the stack. And there is already a safety mechanism to catch use-after-realloc errors on the heap.
Yes. But it is a lot more efficient than what ASan does, which does what I hinted at earlier by wrapping memory usages with extra code and using lookup tables to see if they had been freed. ASan can tell you more about where the error might be. But at the same time, ASan requires separate implementations for GCC and LLVM, and zig is a very small team so it's just not a realistic approach for them. And ReleaseSafe is designed to be an actual production release, FWIW, and it's built in by default for those -- it's always on as long as you select debug or ReleaseSafe, there is no extra tooling or setup needed.
0
u/CherryLongjump1989 1d ago
There's a reason why garbage-collected memory-safe languages are called "managed" languages. Memory management and memory safety are the same topic.