Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How (memory) safe is Zig? (2021)

scattered-thoughts.net

Post reply on HN
Print view View original

11–20 of 88 posts

Re: How (memory) safe is Zig? (2021)

#11

Post by TimSchumann »

KerrAvon wrote: post #6
90s_dev wrote: post #2

> But it does not nearly approach the level of systematic prevention of memory unsafety that rust achieves. Unless I gravely misunderstood Zig when I learned it, the Zig approach to memory safety is to just write a ton of tests fully exercising your functions and let the test allocators find and log all your bugs for you. Not my favorite approach, but your article doesn't seem to take into account this entirely diffe…

What that means, though, is that you have a choice between defining memory unsafely away completely with Rust or Swift, or trying to catch memory problems by a writing a bunch of additional code in Zig.

I’d argue that ‘a bunch of additional code’ to solve for memory safety is exactly what you’re doing in the ‘defining memory safety away’ example with Rust or Swift.

It’s just code you didn’t write and thus likely don’t understand as well.

This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug.

Re: How (memory) safe is Zig? (2021)

#12

Post by pizlonator »

90s_dev wrote: post #9
pizlonator wrote: post #8

Earlier quoted context omitted.

Thank you for considering it :-) Hit me up if you have questions or issues. I’m easy to find

One of these days, a project will catch on that's vastly simpler than any memory solution today, yet solves all the same problems, and more robustly too, just like how it took humanity thousands of years to realize how to use levers to build complex machines. The solution is probably sitting right under our noses. I'm not sure it's your project (maybe it is) but I bet this will happen.

That’s a really great attitude! And I think you’re right!

I think in addition to possibly being the solution to safety for someone, Fil-C is helping to elucidate what memory safe systems programming could look like and that might lead to someone building something even better

Re: How (memory) safe is Zig? (2021)

#13

Post by dnautics »

nanolith wrote: post #3

There is a third category of memory and other software safety mechanisms: model checking. While it does involve compiling software to a different target -- typically an SMT solver -- it is not a compile-time mechanism like in Rust. Kani is a model checker for Rust, and CBMC is a model checker for C. I'm not aware of one (yet!) for Zig, but it would not be difficult to build a port. Both Kani and CBMC compile down to…

There isn't a real one yet, but to scratch an itch I tried to build one for Zig. It's not complete nor do I have plans to complete it. https://github.com/ityonemo/clr

If zig locks down the AIR (intermediate representation at the function level) it would be ideal for running model checking of various sorts. Just by looking at AIR I found it possible to:

- identify stack pointer leakage

- basic borrow checking

- detect memory leaks

- assign units to variables and track when units are incompatible

Re: How (memory) safe is Zig? (2021)

#14

Post by ajross »

KerrAvon wrote: post #6
90s_dev wrote: post #2

> But it does not nearly approach the level of systematic prevention of memory unsafety that rust achieves. Unless I gravely misunderstood Zig when I learned it, the Zig approach to memory safety is to just write a ton of tests fully exercising your functions and let the test allocators find and log all your bugs for you. Not my favorite approach, but your article doesn't seem to take into account this entirely diffe…

What that means, though, is that you have a choice between defining memory unsafely away completely with Rust or Swift, or trying to catch memory problems by a writing a bunch of additional code in Zig.

Weird that Swift is your totem for "managed/collected runtime" and not Java (or C#/.NET, or Go, or even Javascript). I mean, it fits the bill, but it's hardly the best didactic choice.

Re: How (memory) safe is Zig? (2021)

#15

Post by Dwedit »

If you're filling uninitialized pointers with AAAAAAAA, it might be best to also reserve that memory page and mark it as no-access.

I'm not even joking. Any pattern used by magic numbers that fill pointers (such as HeapFree filling memory with FEEEEEEE on Windows) should have a corresponding no-access page just to ensure that the program will instantly fail, and not have a valid memory allocation mapped in there. For 32-bit programs, everything past 0x8000000 used to be reserved as kernel memory, and have an access violation when you access it, so the magic numbers were all above 0x80000000. But with large address aware programs, you don't get that anymore, only manually reserving the 4K memory pages containing the magic numbers will give you the same effect.

Re: How (memory) safe is Zig? (2021)

#16

Post by throwawaymaths »

Dwedit wrote: post #15

If you're filling uninitialized pointers with AAAAAAAA, it might be best to also reserve that memory page and mark it as no-access. I'm not even joking. Any pattern used by magic numbers that fill pointers (such as HeapFree filling memory with FEEEEEEE on Windows) should have a corresponding no-access page just to ensure that the program will instantly fail, and not have a valid memory allocation mapped in there. For…

that only happens in debug-builds.

https://ziglang.org/documentation/master/#undefined

Re: How (memory) safe is Zig? (2021)

#17

Post by 90s_dev »

KerrAvon wrote: post #6
90s_dev wrote: post #2

> But it does not nearly approach the level of systematic prevention of memory unsafety that rust achieves. Unless I gravely misunderstood Zig when I learned it, the Zig approach to memory safety is to just write a ton of tests fully exercising your functions and let the test allocators find and log all your bugs for you. Not my favorite approach, but your article doesn't seem to take into account this entirely diffe…

What that means, though, is that you have a choice between defining memory unsafely away completely with Rust or Swift, or trying to catch memory problems by a writing a bunch of additional code in Zig.

What if -- stay with me now -- what if we solved it by just writing vastly less code, and having actually reusable code, instead of reinventing every type of wheel in every project? Maybe that's the real secret to sound code. Actual code reuse. I know it's a pipedream, but a man can dream, can't he?

Re: How (memory) safe is Zig? (2021)

#18

Post by dang »

Related:

How safe is Zig? - https://news.ycombinator.com/item?id=31850347 - June 2022 (254 comments)

How Safe Is Zig? - https://news.ycombinator.com/item?id=26537693 - March 2021 (274 comments)

How Safe Is Zig? - https://news.ycombinator.com/item?id=26527848 - March 2021 (1 comment)

How Safe Is Zig? - https://news.ycombinator.com/item?id=26521539 - March 2021 (1 comment)

Re: How (memory) safe is Zig? (2021)

#19

Post by codr7 »

90s_dev wrote: post #17
KerrAvon wrote: post #6

Earlier quoted context omitted.

What that means, though, is that you have a choice between defining memory unsafely away completely with Rust or Swift, or trying to catch memory problems by a writing a bunch of additional code in Zig.

What if -- stay with me now -- what if we solved it by just writing vastly less code , and having actually reusable code, instead of reinventing every type of wheel in every project? Maybe that's the real secret to sound code. Actual code reuse. I know it's a pipedream, but a man can dream, can't he?

The way we've done code reuse up to this point rarely lives up to its promises.

I don't know what the solution is, but these days I'm a lot more likely to simply copy code over to a new project rather than try to build general purpose libraries.

I feel like that's part of the mess Rust/Swift are getting themselves tangled up in, everything depends on everything which turns evolution into more and more of an uphill struggle.

Re: How (memory) safe is Zig? (2021)

#20

Post by agarren »

TimSchumann wrote: post #11
KerrAvon wrote: post #6

Earlier quoted context omitted.

What that means, though, is that you have a choice between defining memory unsafely away completely with Rust or Swift, or trying to catch memory problems by a writing a bunch of additional code in Zig.

I’d argue that ‘a bunch of additional code’ to solve for memory safety is exactly what you’re doing in the ‘defining memory safety away’ example with Rust or Swift. It’s just code you didn’t write and thus likely don’t understand as well. This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug.

That sounds a bit unfair. All that code that we neither wrote nor understood, I think in the case of Rust, it’s either the borrow checker or the compiler itself doing something it does best - i.e., “defining memory safety away”. If that’s the case, then labeling such tooling and language-enforced memory safety mechanisms as “a bunch of additional code…you didn’t write and…don’t understand” appears somewhat inaccurate, no?
Post reply on HN