3 ms·
Zig at least claims some level of memory safety in their marketing. How real that is I don't know.
by lmm 11mo ago
Zig at least claims some level of memory safety in their marketing. How real that is I don't know.
- vlovich123 11mo agoAbout as real as claiming that C/C++ is memory safe because of sanitizers IMHO.
- Ygg2 11mo agoI mean, Zig does have non-null pointers. It prevents some UB. Just not all.
- pjmlp 11mo agoWhich you can achieve in C and C++ with static analysis rules, breaking compilation if pointers aren't checked for nullptr/NULL before use. Zig would have been a nice proposition in the 20th century, alongside languages like Modula-2 and Object Pascal.
- tomnipotent 11mo agoI'm unaware of any such marketing.
- dwattttt 11mo agoZig does claim that it > ... has a debug allocator that maintains memory safety in the face of use-after-free and double-free which is probably true (in that it's not possible to violate memory safety on the debug allocator, although it's still a strong claim). But beyond that there isn't really any current marketing for Zig claiming safety, beyond a heading in an overview of "Performance and Safety: Choose Two".
- gf000 11mo agoRuntime checks can only validate code paths taken, though. Also, C sanitizers are quite good as well nowadays.
- tomnipotent 11mo agoThat's a library feature (not intended for release builds), not a language feature.
- weebull 11mo agoIt is intended for release builds. The ReleaseSafe target will keep the checks. ReleaseFast and ReleaseSmall will remove the checks, but those aren't the recommended release modes for general software. Only for when performance or size are critical.
- tomnipotent 11mo agoDebugAllocator essentially becomes a no-op wrapper when you use those targets.
- gjajric 11mo agoI have heard different arguments, such as https://zackoverflow.dev/writing/unsafe-rust-vs-zig/ https://zackoverflow.dev/writing/unsafe-rust-vs-zig/ .