[elcritch]

> This is a severe problem, and I predict that this is going to cause real security issues

That is a nasty problem, particularly in larger projects with different subsystems interacting (like say an xml parser and another).

I suspect it's worse in some ways as Zig has good marketing as being "safer" language despite still having the same fundamental memory flaws as C/C++. In the worse case that could lull programmers into complacency. I mean it looks "modern" so it's safe right? Just do some testing and it's all good.

Currently I'm skeptical Zig will get a production-ready memory safety. Currently there's only GC's or linear/affine types and Zig doesn't appear to be pursuing either. Aliased pointers aren't something that's properly handled by adhoc testing IMHO.

[Laremere]

FWIW, "safe" doesn't appear anywhere on the Zig homepage. I've been trying out Zig for the past couple weeks, and while I love it so far, it gives anything but the feeling of safety. I would say there's guardrails, but those are optionally disabled in the compiler for faster execution.

It seems to be that Zig is really not trying to be a replacement for all programming, but fill its niche as best it can. If your niche requires memory safety as a top priority because it accepts untrusted input, Rust would probably be a better choice than Zig.

[kvark]

Reminds me of modern C++, where the language and standard library features all work together to increase safety. And then it backfires because you feel like it's safe, but in reality it's not, and bugs still happen, they just catch you off-guard.

[pcwalton]

Some sort of pointer tagging system, like 128-bit pointers where the upper word is a unique generation ID, might be the simplest approach to eliminate security problems from use-after-free, but it's going to have some amount of runtime overhead (though new hardware features may help to reduce it).

Alternately, use a GC.

[azakai]

Another option is something like Type-After-Type (make allocations use type-specific regions, so use-after-free is still fully type safe at least):

https://download.vusec.net/papers/tat_acsac18.pdf

[pcwalton]

Yes, something like that may work. Note that this approach also has time and memory overhead quoted in the paper. There's no free lunch.