4 ms·

I love Zig and I love that it’s getting attention, but can someone convince me of its memory safety? One thing that surprised me is that returning pointers to s

I love Zig and I love that it’s getting attention, but can someone convince me of its memory safety? One thing that surprised me is that returning pointers to stack-allocated memory doesn’t cause a compiler error — it just segfaults at runtime. This has been an open issue since 2019 [#1]. That, along with the number of memory-related issues in one of Zig’s most popular project, Bun.js [#2], gives me pause. [#1]: https://github.com/ziglang/zig/issues/2646 https://github.com/ziglang/zig/issues/2646 [#2]: https://github.com/oven-sh/bun/issues?q=is%3Aissue+segfault https://github.com/oven-sh/bun/issues?q=is%3Aissue+segfault

lukaslalinsky 2y ago
Zig is not memory safe, there is no way around it. It's really only as safe as C, with some helpers for making it easier to write safe code. You should really not use Zig unless you are prepared to deal with memory safety on your own. That makes it a good low-level language for system programming, but a VERY bad general purpose language. I'm writing this as a fan of Zig.
- ngrilly 2y ago
  Unlike C, Zig offers spatial memory safety, but it does not offer temporal memory safety.
  - do_not_redeem 2y ago
    Zig only has spatial memory safety in limited situations. For example: If you use many-pointers anywhere in your codebase, those places have no spatial memory safety. If you compile in ReleaseFast, you have no spatial memory safety at all.
    - throwawaymaths 2y ago
      in practice though you should be compiling ReleaseSafe and activating ReleaseFast only in functions where you need it (and that is the default)
      - lukaslalinsky 2y ago
        Even the Zig compiler is built with ReleaseFast for the published binaries.
        throwawaymaths 2y ago
        not sure what you think the safety parameters for compilation should be.
- dragonelite 2y ago
  Because its not so strict and safe as Rust is what brings me joy for hobby and recreational programming. Its easy to track how and when memory is allocated because you need to pass an allocator to do it.
deleted 2y ago
[deleted]
Rendello 2y ago
There was a discussion yesterday in which the blog author stated (and elaborated on) "I strongly disagree that Zig is safer than — even — unsafe Rust. Anyone telling you otherwise is either purposefully lying, or ignorant". That has been my experience as well. The sorts of errors I ran into were the same as in my C and HolyC experience, and not the sorts of errors I get with Rust.
- Rendello 2y ago
  I meant to link it earlier: https://news.ycombinator.com/item?id=42942618 https://news.ycombinator.com/item?id=42942618
- throw-the-towel 2y ago
  Wait, how come you even have HolyC experience?
  - Rendello 2y ago
    For a few years I was a highly-paid TempleOS sysadmin for a fortune 500 company. Just kidding ;) It was hobby development, of course. Building demos and games in HolyC was how I finally started learning lower-level software.
- cztomsik 2y ago
  Rust is generally safer than Zig, but unsafe Rust is/was (mid)designed in such way that it's almost guaranteed to blow in your face eventually. I don't know if mutable noalias has been already enabled for good, but even if there are no changes between compiler versions, those mutable noalias rules are super-tricky to get right. In Zig, a pointer is just regular thing, you take care, but most pointers are arena-allocated anyway, and that's a bit like runtime-branded lifetime (which is great and Rust cannot do that, at least not in idiomatic Rust).
modernerd 2y ago
It’s not memory safe. People say, “oh, it’s safer than C because tests can warn of missed deinits” but the fact is it isn’t memory safe by design and it’s not a priority for the language. There are still reasons to use it and there are domains where memory safety isn’t a priority, but memory safety depends on the same mix of linters, code review, simple memory models, a deep understanding of how memory works, minimal dependencies and luck just like in C. Although none of those things will save you on their own or combined. If memory safety is a priority I’d consider other languages.
pjmlp 2y ago
Think Modula-2, Object Pascal safety. Much better than C will ever be, but still with gotchas like use after free, or hardware mapped variables.
matu3ba 2y ago
Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Sanitation is very much possible, so it is no design problem, see https://matu3ba.github.io/articles/optimal_debugging/#practice https://matu3ba.github.io/articles/optimal_debugging/#practi.... More interesting would be threading and process/shared memory synchronization problems and limitations. At least on Linux in theory the latter should be fuzzable with scheduler API, but I am unaware of solutions. The former works via thread sanitizer, undo thread fuzzing and rr chaos mode, but I am unaware of solutions to test lock- and wait-free code besides trying really hard to create race conditions and comparing expected results to observe the race conditions, which does not cover temporal race conditions not observable at a later point. Your statement like the general "safety" discussion is missing numbers on compilation time vs run time cost and coverage or any form of metrics to estimate risk vs benefit with cut-off values. Specifically input set/formulae coverage for functions and component planning would be interesting to discuss systems at scale (not basic code coverage), but I am unable to get decent information on that.
- lolinder 2y ago
  > Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Does a stack overflow trigger a crash, or does it cause undefined behavior and/or remote code execution? You'd have a point if it's the latter, but I also assumed that I would have heard about it before if that were true. And if it's not the latter, then it's not a failure of memory safety as most people mean it.
  - steveklabnik 2y ago
    There’s stack probes that cause an abort.
- bikeshaving 2y ago
  My definition of safety is simply how many memory/UB bugs escape to production. This is quantifiable. Looking at open-source Zig projects, even highly competent programmers seem to be struggling. I’d love to dig deeper into what’s causing all these panics: how much comes from Zig’s great interop story, how much from common language footguns, and how much from its non-global-allocator-passing philosophy?
throwawaymaths 2y ago
in principle static checking of memory safety in zig could be a thing, but there are some minor obstacles: https://github.com/ityonemo/clr https://github.com/ityonemo/clr
esjeon 2y ago
Zig is unsafe, but, instead, it encourages more strategic approaches for memory management. Period. In case of Bun, it's kind of mixed bag, as it relies on JSCore from WebKit. A lot of its issues are from the the engine.
baranul 2y ago
A lot of people have put Zig on pause or have outright rejected it. Nothing wrong with that (personal choice). Tsoding (well known YouTube programmer) makes fun of it and won't use it unless paid to. Context is needed, in regards to safety. Zig, attempts to be safer than C, but then so do many other C alternatives and replacements. C3, Odin, Jai, Nim, D, etc... In fact, V (Vlang) could be seen as making a better argument for safety, because it provides even more default safety features and uses an optional GC. None of its libraries depend on the GC and it can be completely turned off (via cmdline flag).

lukaslalinsky 2y ago

Zig is not memory safe, there is no way around it. It's really only as safe as C, with some helpers for making it easier to write safe code. You should really not use Zig unless you are prepared to deal with memory safety on your own. That makes it a good low-level language for system programming, but a VERY bad general purpose language. I'm writing this as a fan of Zig.

ngrilly 2y ago
Unlike C, Zig offers spatial memory safety, but it does not offer temporal memory safety.
- do_not_redeem 2y ago
  Zig only has spatial memory safety in limited situations. For example: If you use many-pointers anywhere in your codebase, those places have no spatial memory safety. If you compile in ReleaseFast, you have no spatial memory safety at all.
  - throwawaymaths 2y ago
    in practice though you should be compiling ReleaseSafe and activating ReleaseFast only in functions where you need it (and that is the default)
    - lukaslalinsky 2y ago
      Even the Zig compiler is built with ReleaseFast for the published binaries.
      - throwawaymaths 2y ago
        not sure what you think the safety parameters for compilation should be.
dragonelite 2y ago
Because its not so strict and safe as Rust is what brings me joy for hobby and recreational programming. Its easy to track how and when memory is allocated because you need to pass an allocator to do it.

deleted 2y ago

[deleted]

Rendello 2y ago

There was a discussion yesterday in which the blog author stated (and elaborated on) "I strongly disagree that Zig is safer than — even — unsafe Rust. Anyone telling you otherwise is either purposefully lying, or ignorant". That has been my experience as well. The sorts of errors I ran into were the same as in my C and HolyC experience, and not the sorts of errors I get with Rust.

Rendello 2y ago
I meant to link it earlier: https://news.ycombinator.com/item?id=42942618 https://news.ycombinator.com/item?id=42942618
throw-the-towel 2y ago
Wait, how come you even have HolyC experience?
- Rendello 2y ago
  For a few years I was a highly-paid TempleOS sysadmin for a fortune 500 company. Just kidding ;) It was hobby development, of course. Building demos and games in HolyC was how I finally started learning lower-level software.
cztomsik 2y ago
Rust is generally safer than Zig, but unsafe Rust is/was (mid)designed in such way that it's almost guaranteed to blow in your face eventually. I don't know if mutable noalias has been already enabled for good, but even if there are no changes between compiler versions, those mutable noalias rules are super-tricky to get right. In Zig, a pointer is just regular thing, you take care, but most pointers are arena-allocated anyway, and that's a bit like runtime-branded lifetime (which is great and Rust cannot do that, at least not in idiomatic Rust).

modernerd 2y ago

It’s not memory safe. People say, “oh, it’s safer than C because tests can warn of missed deinits” but the fact is it isn’t memory safe by design and it’s not a priority for the language. There are still reasons to use it and there are domains where memory safety isn’t a priority, but memory safety depends on the same mix of linters, code review, simple memory models, a deep understanding of how memory works, minimal dependencies and luck just like in C. Although none of those things will save you on their own or combined. If memory safety is a priority I’d consider other languages.

pjmlp 2y ago

Think Modula-2, Object Pascal safety. Much better than C will ever be, but still with gotchas like use after free, or hardware mapped variables.

matu3ba 2y ago

Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Sanitation is very much possible, so it is no design problem, see https://matu3ba.github.io/articles/optimal_debugging/#practice https://matu3ba.github.io/articles/optimal_debugging/#practi.... More interesting would be threading and process/shared memory synchronization problems and limitations. At least on Linux in theory the latter should be fuzzable with scheduler API, but I am unaware of solutions. The former works via thread sanitizer, undo thread fuzzing and rr chaos mode, but I am unaware of solutions to test lock- and wait-free code besides trying really hard to create race conditions and comparing expected results to observe the race conditions, which does not cover temporal race conditions not observable at a later point. Your statement like the general "safety" discussion is missing numbers on compilation time vs run time cost and coverage or any form of metrics to estimate risk vs benefit with cut-off values. Specifically input set/formulae coverage for functions and component planning would be interesting to discuss systems at scale (not basic code coverage), but I am unable to get decent information on that.

lolinder 2y ago
> Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Does a stack overflow trigger a crash, or does it cause undefined behavior and/or remote code execution? You'd have a point if it's the latter, but I also assumed that I would have heard about it before if that were true. And if it's not the latter, then it's not a failure of memory safety as most people mean it.
- steveklabnik 2y ago
  There’s stack probes that cause an abort.
bikeshaving 2y ago
My definition of safety is simply how many memory/UB bugs escape to production. This is quantifiable. Looking at open-source Zig projects, even highly competent programmers seem to be struggling. I’d love to dig deeper into what’s causing all these panics: how much comes from Zig’s great interop story, how much from common language footguns, and how much from its non-global-allocator-passing philosophy?

throwawaymaths 2y ago

in principle static checking of memory safety in zig could be a thing, but there are some minor obstacles: https://github.com/ityonemo/clr https://github.com/ityonemo/clr

esjeon 2y ago

Zig is unsafe, but, instead, it encourages more strategic approaches for memory management. Period. In case of Bun, it's kind of mixed bag, as it relies on JSCore from WebKit. A lot of its issues are from the the engine.

baranul 2y ago

A lot of people have put Zig on pause or have outright rejected it. Nothing wrong with that (personal choice). Tsoding (well known YouTube programmer) makes fun of it and won't use it unless paid to. Context is needed, in regards to safety. Zig, attempts to be safer than C, but then so do many other C alternatives and replacements. C3, Odin, Jai, Nim, D, etc... In fact, V (Vlang) could be seen as making a better argument for safety, because it provides even more default safety features and uses an optional GC. None of its libraries depend on the GC and it can be completely turned off (via cmdline flag).