Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

Not sure what 'story' is intended to mean here. Is use-after-free undefined behaviour in Zig?

There isn't really anything in the language that prevents use-after-free, partially because allocation isn't even part of the language and exists entirely in userland code. However, IIRC the standard library does include an allocator that tries to detect use-after-free.

Isn't that an intentional design decision in Zig? As far as I understood, Zig isn't trying to "solve" memory management, it's trying to provide manual memory management with better tools than C to help you do it right, but it's explicitly not trying to save you from yourself in this respect.

Except that C and C++ already provide similar tools, one just needs to actually enable them.

I don't follow. You recently pointed out to me that most of the serious security bugs in the Chromium codebase (C++) are rooted in memory-management. [0] It's no simple thing to fix these bugs. Not even Google can do so in their most treasured code.

[0] https://news.ycombinator.com/item?id=26862330

The point being that Zig improves very little regarding that, because it is based on the same kind of tooling.

> allocation isn't even part of the language

It's not supposed to be. In most cases, memory allocation is an operating system concept. As a systems programming language, zig must not abstract this away from the programmer.

Allocation isn’t part of the core language in Rust either, yet it prevents use-after-free generically via RAII

Currently I'm using Rust in a project without RAII. RAII is neither necessary nor sufficient to prevent use-after-free. In Rust use-after-free is prevented by the borrow-checker. In C++ with RAII use-after-free is still possible, because normal references aren't tracked with regard to the lifetime of pointees.

Microsoft and Google are trying to improve it via lifetime analysis, but after 3 years it is still pretty much WIP due to C++ semantics.

You don't need allocations to be part of the language, you just need destructors (or linear types.) But the Zig authors intentionally omitted destructors because they want all control flow to be explicit. There's more at [0].

Side note: the proposal at [0] seems very close to [1].

[0]: https://github.com/ziglang/zig/issues/782

[1]: https://www.haskellforall.com/2013/06/the-resource-applicati...

Too late to edit, but: I'm an idiot, I was thinking of memory leaks, not use-after-free.

Is use-after-free ever really defined behavior?

That would depend on the language and the libraries.

You could roll your own 'safe' memory pool in C such that use-after-free doesn't produce undefined behaviour. You'd still have a bug, but it wouldn't have to invoke UB at the level of the C programming language.

Yes. Undefined behavior exists only in standards. It's perfectly possible for implementations to define everything.

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application:

> it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away.

> The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing.

> They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

Reply on news.ycombinator.com