Re:Why Zig over C for Systems Programming
by 0c3ca83 on Friday November 13, 2026 @12:03PM
(#50486373)
Where do you think the static analyzers are baked into for C?
gcc -fanalyze ...
clang -fsanitize=address ...
etc
Re:Why Zig over C for Systems Programming
by logicchains on Friday November 13, 2026 @12:25PM
(#50486687)
Those aren't static analyzers, they're dynamic analyzers; they only catch issues at runtime.
Re:Why Zig over C for Systems Programming
by 0c3ca83 on Friday November 13, 2026 @12:38PM
(#50486895)
GCC's -fanalyze, and clang's `--analyze` both run static analyzers.
Re:Why Zig over C for Systems Programming
by metaltyphoon on Friday November 13, 2026 @12:42PM
(#50486983)
If this is such a good default, why make me type `-fsanatize=address? Why isn't this the default when not doing "release mode"?
Re:Why Zig over C for Systems Programming
by woodruffw on Friday November 13, 2026 @12:53PM
(#50487150)
It adds nontrivial runtime cost. It’s also not a perfect mitigation (there are plenty of unsound patterns that ASan, UBSan, and TSan won’t catch).
Re:Why Zig over C for Systems Programming
by William_BB on Friday November 13, 2026 @12:55PM
(#50487183)
The obvious answer is that I don't want to pay for these checks at runtime and can catch most of these bugs at test time. There are definitely use cases where that's acceptable.
Re:Why Zig over C for Systems Programming
by William_BB on Friday November 13, 2026 @12:45PM
(#50487029)
I meant static analyzers like clang-tidy and cppcheck. `-fanalyze` I suppose is a fair comparison, but `fsanitize` is not since it's not even static
Re:Why Zig over C for Systems Programming
by 0c3ca83 on Friday November 13, 2026 @04:24PM
(#50489957)
Yes. Both clang and GCC come with static analyzers built in. Clangs supports whole program static analysis.
Re:Why Zig over C for Systems Programming
by dnautics on Friday November 13, 2026 @12:49PM
(#50487080)
I'm very certain you can statically analyze zig's IR. And zig makes it easier to get consistency because you are steered away from the mishmash of malloc/jemalloc/pick-your-allocator-function. (The analyzer can say "all bets are off if you don't use the allocator interface") same with the new stdlib io interface for async-shaped analysis on aliasing analysis
github.com/ityonemo/clr
Though I've noticed the same trend when reading a famous Rust primer for C++ developers. Like there are obviously so many good and valid arguments when comparing the two languages that would've gotten the point across. Yet the authors felt the need to push it one step further, where the comparison no longer seems fair. Like comparing Rust with C++17 when C++20 provides the same exact feature that Rust claims to provide.