5 ms·

Zig gives buffer overflow safety and null pointer safety but not use after free, double free, or stack pointer escape safety. Zig also gives you memory exhaust

Zig gives buffer overflow safety and null pointer safety but not use after free, double free, or stack pointer escape safety. Zig also gives you memory exhaustion safety which rust does not.

oconnor663 3y ago
Is there a memory exhaustion scenario where Rust does something other than panic?
- kibwen 3y ago
  Rust-the-language doesn't do any dynamic allocation, so it doesn't exhaust memory at all. The Rust stdlib currently guarantees an abort on OOM, but in the future this will be changed to a panic (which you can always configure to be an abort if you want). Both of these behaviors are memory-safe (it's unclear what "memory exhaustion safety" is referring to).
  - throwawaymaths 3y ago
    Also to clarify: there are platforms (like linux) which de facto have nonfailable allocation, if you run out of memory the system will oom kill your process, and neither zig nor rust will save you from that. I believe In practice the most common place where failable OOM is a big deal is in embedded systems programming
    - 10000truths 3y ago
      No language can save you from OOMs, but because Zig pervasively uses explicit memory allocation, it makes it easy to greatly mitigate OOM risks by front-loading all the fallibility: 1. Calculate and allocate all your required memory immediately upon process startup (including memory from OS resources like sockets) 2. Call mlockall to prevent the pages from being swapped out 3. Write "-1000" to /proc/self/oom_score_adj to avoid the OOM killer 4. Use your preallocated memory as a pool for all further allocations With the above approach, the application has full control over how to handle application-level OOMs (e.g. applying backpressure to connecting clients, or shrinking non-critical caches) once it is past the start-up stage.
  - throwawaymaths 3y ago
    > memory exhaustion safety Sure this more like DDOS mitigation, so it memory related safety, not memory safety.
- pitaj 3y ago
  You can use the fallible allocation APIs such as `Vec::try_reserve`
gpanders 3y ago
>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 https://github.com/ziglang/zig/issues/2646 [2]: https://github.com/ziglang/zig/issues/2301 https://github.com/ziglang/zig/issues/2301
- jmull 3y ago
  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 3y ago
    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")
pitaj 3y ago
What do you mean by memory exhaustion safety?

Zig gives buffer overflow safety and null pointer safety but not use after free, double free, or stack pointer escape safety. Zig also gives you memory exhaustion safety which rust does not.

oconnor663 3y ago

Is there a memory exhaustion scenario where Rust does something other than panic?

kibwen 3y ago
Rust-the-language doesn't do any dynamic allocation, so it doesn't exhaust memory at all. The Rust stdlib currently guarantees an abort on OOM, but in the future this will be changed to a panic (which you can always configure to be an abort if you want). Both of these behaviors are memory-safe (it's unclear what "memory exhaustion safety" is referring to).
- throwawaymaths 3y ago
  Also to clarify: there are platforms (like linux) which de facto have nonfailable allocation, if you run out of memory the system will oom kill your process, and neither zig nor rust will save you from that. I believe In practice the most common place where failable OOM is a big deal is in embedded systems programming
  - 10000truths 3y ago
    No language can save you from OOMs, but because Zig pervasively uses explicit memory allocation, it makes it easy to greatly mitigate OOM risks by front-loading all the fallibility: 1. Calculate and allocate all your required memory immediately upon process startup (including memory from OS resources like sockets) 2. Call mlockall to prevent the pages from being swapped out 3. Write "-1000" to /proc/self/oom_score_adj to avoid the OOM killer 4. Use your preallocated memory as a pool for all further allocations With the above approach, the application has full control over how to handle application-level OOMs (e.g. applying backpressure to connecting clients, or shrinking non-critical caches) once it is past the start-up stage.
- throwawaymaths 3y ago
  > memory exhaustion safety Sure this more like DDOS mitigation, so it memory related safety, not memory safety.
pitaj 3y ago
You can use the fallible allocation APIs such as `Vec::try_reserve`

gpanders 3y ago

>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 https://github.com/ziglang/zig/issues/2646 [2]: https://github.com/ziglang/zig/issues/2301 https://github.com/ziglang/zig/issues/2301

jmull 3y ago
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 3y ago
  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")

pitaj 3y ago

What do you mean by memory exhaustion safety?