| > There are no such invariants in Zig. Zig does have invariants. It doesn't have an aliasing invariant like rust though, but it does have its own invariants, naturally. Zig is a memory unsafe language. > Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness". A reachable bug means one that can be triggered. Undefined behavior does not mean a bug can be triggered. > There's a neat class of UBs called "immediate UB"s. They can ruin the code just by being compiled, instead of reached at runtime. And guess what? They have a lot of these. Can be, yes. > Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools This is only possible if unsafe is used. `unsafe` is grep'able, hence all memory safety bugs are grep'able. That's the whole point of rust. |
Not these in particular. You are again ignoring the context.
> Undefined behavior does not mean a bug can be triggered.
Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions:
https://predr.ag/blog/falsehoods-programmers-believe-about-u...
> `unsafe` is grep'able, hence all memory safety bugs are grep'able.
Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".
No. Even assuming everything is done idiomatically, memory safety bugs can still originate from unsafe blocks and all the safe functions in the same module. So we want the module containing unsafe to be small and closed. Otoh with this code base unsafe lives in every module.
Making them encapsulated is the whole point of Rust, in this code nothing is encapsulated so no, they missed the whole point of it.
Aaand it's not like you can just remove the unsafe blocks one by one trivially. It's as hard as rewriting the codebase from ground up without reference (unlike the current migration) as every referenced object in the call graph needs to be reordered. Well partly because the original code sucks I assume.