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).
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.
@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.
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
unsafeusage, obviously).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.
@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.
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.