zig does have guard rails, they're just different approaches. zig defaults to optional types where null must be handled. and memory safety is checked through unit testing and exposing debugger memory allocators that check for different memory corruption bugs.

rust takes a shift left approach where all declarations drive safety whereas zig takes a more laid back shift right where it's expected you'll have written tests. rust will force all developers to conform to produce good code where zig requires a bit more though, i mean every dev writes test cases right?

[–] BB_C@programming.dev 2 points 5 hours ago

and memory safety is checked through unit testing

🤣 🤣🤣🤣🤣🤣

[–] SorteKanin@feddit.dk 1 points 5 hours ago (2 children)

Saying that "memory safety is checked by tests" is basically saying "memory safety is not checked". Yes, you can write tests. How do you know the tests cover all cases? How do you know the tests aren't buggy?

Also, what about memory safety across threads? Are you testing multi-threaded scenarios? Are you ensuring you have no data races?

I also don't understand how this is an argument for Zig over C. You can also test memory safety of your C code via various means, but it's never a guarantee. Zig is the same. So again, it seems a bit more pointless to go from C to Zig. Going from C to Rust brings actual tangible guarantees of memory safety (outside of any unsafe usage, obviously).

[–] kewjo@lemmy.world 1 points 2 hours ago

in c code you will see malloc, alloc, free w/e scattered through the code base, most static tools lack because they don't control the memory and just analyze address spaces or do static code analysis. they look top down and try to catch errors.

zig's design forces you to create a memory allocator before any object initializations (alloc/free) and is typically constructed at the top level and passed through to functions. this allows you to swap implementation easily and use the allocator to claim memory or return an error to the caller if it can't.

you can do some simple static allocator, general purpose allocator (can grow memory space as you allocate more objects) or in this case to test memory safety a debug allocator which you use in your tests. This moves the memory inspection inside of where your program allocates memory. this is more of an inside out approach where the analysis is produced by controlling the memory allocations and frees through a standard interface.

[–] liberty@mathstodon.xyz 1 points 4 hours ago (1 children)

@SorteKanin @kewjo Fuzzing! Zig is working on an integrated fuzzer that will work seamlessly with the testing system.

And for those cases you don't catch, there's ReleaseSafe which have runtime checks to prevent illegal behavior.

Zig removes a lot of the footguns of C and also provides a lot of the tools you'll need anyway built-in. The debug allocator does leak-checking. You have to unwrap your nulls. There is compile-time duck-typing so generic data structures don't have to rely on void pointers. Also no separate preprocessor language.

[–] SorteKanin@feddit.dk 1 points 4 hours ago

ReleaseSafe which have runtime checks to prevent illegal behavior

To prevent some illegal behaviour. Again, I'm not an expert on Zig, but as far as I understand, even Release"Safe" is not actually memory safe.