[gpanders]

>Zig gives buffer overflow safety and null pointer safety but not use after free, double free

It can provide the latter two through the use of the `GeneralPurposeAllocator`, which tracks UAF and double free.

Stack pointer escape safety is being actively researched (there are a few tracking issues, see [1]). I'm personally interested in this, I've written a decent-ish amount of Zig for toy/personal projects, and anecdotally stack pointer escape is the only type of memory error that has bitten me more than once (though to be fair, one of these cases was calling into a C API, so even Rust wouldn't have helped).

More broadly, the ability to catch all forms of UB in Debug/safety builds is an accepted proposal [2], though whether or not it will be possible in practice is a different (and interesting!) question.

[1]: https://github.com/ziglang/zig/issues/2646

[2]: https://github.com/ziglang/zig/issues/2301

[SkiFire13]

The way `GeneralPurposeAllocator` works is kinda scary though, since it may result in whole memory pages used only for very small allocations, effectively multiplying the memory usage of the program. Also kinda goes against the memory exhaustion safety, since now you're more likely to exhaust memory.

[jmull]

Yeah, I don't think it's right to say Zig doesn't have use-after-free and double-free safety. If you want that, you can just use a general purpose allocator. Note that you can't forget to choose an allocator since they are explicit.

Is this somehow harder than, say, choosing not to use "unsafe" in Rust?

Maybe all that is missing is a linter to help enforce whatever memory-management policy you've decided on. That's not really needed for small, coherent teams, but would be important for using Zig in larger projects with multiple teams and/or disparate individual contributors. (Perhaps such a thing exists and I just don't know about it.)

You might also be able to use an arena allocator where free is a no-op. That has different tradeoffs, but is also safe for use-after-free and double-free.

As you say, stack escape is the main thing where Zig doesn't have a good memory-safety story yet (at least not that I've heard). I guess there are a few others that concern me when I see them on a list, though I haven't hit them in real life.

[throwawaymaths]

Static analysis at the IR level would be awesome. It could catch use-undefined, stack escape, and probably uaf/df as well so you don't have to lean on gpa's (potentially expensive) tricks. Plus there are times when you maybe don't want to use page allocator.

As an aside. I'm not certain I understand how double free is memory unsafe (in the sense of "causing vulnerabilities")

[saagarjha]

C has use-after-free and double-free safety if you patch out free. Not really a solution, is it?

[saagarjha]

An allocator that does heap quarantining at the page level is not a "general purpose allocator". It is a debug tool.