3 ms·

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 us

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.

skohan 6y ago
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.
- pjmlp 6y ago
  Except that C and C++ already provide similar tools, one just needs to actually enable them.
  - MaxBarraclough 6y ago
    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 https://news.ycombinator.com/item?id=26862330
    - pjmlp 6y ago
      The point being that Zig improves very little regarding that, because it is based on the same kind of tooling.
matheusmoreira 6y ago
> 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.
Ar-Curunir 6y ago
Allocation isn’t part of the core language in Rust either, yet it prevents use-after-free generically via RAII
- yakubin 6y ago
  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.
  - pjmlp 6y ago
    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.
creata 6y ago
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 https://github.com/ziglang/zig/issues/782 [1]: https://www.haskellforall.com/2013/06/the-resource-applicative.html https://www.haskellforall.com/2013/06/the-resource-applicati...
- creata 5y ago
  Too late to edit, but: I'm an idiot, I was thinking of memory leaks, not use-after-free.

skohan 6y ago

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.

pjmlp 6y ago
Except that C and C++ already provide similar tools, one just needs to actually enable them.
- MaxBarraclough 6y ago
  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 https://news.ycombinator.com/item?id=26862330
  - pjmlp 6y ago
    The point being that Zig improves very little regarding that, because it is based on the same kind of tooling.

matheusmoreira 6y ago

> 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.

Ar-Curunir 6y ago

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

yakubin 6y ago
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.
- pjmlp 6y ago
  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.

creata 6y ago

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 https://github.com/ziglang/zig/issues/782 [1]: https://www.haskellforall.com/2013/06/the-resource-applicative.html https://www.haskellforall.com/2013/06/the-resource-applicati...

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