[endospore]

There wasn't a reply button on your latest reply so I'm posting here instead. Also because I now have more time to clarify what's exactly wrong about the claims.

> who says that the same invariants weren't broken on the Zig side

There are no such invariants in Zig.

> "unsafe invariant broken" does not strictly mean that there's a reachable bug.

Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".

> callers may never actually trigger a bad invariant in an unsafe block.

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.

> potential, grep'able bugs

We are indeed going in circles but I have to ask: you still don't understand that? Grep works for violated lints, unsafe blocks and all things explicitly exist in the code. Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools. They also have thousands of those. It's unfair to say the unsoundness is freshly introduced by the port, but Rust also doesn't help in this way where no unsafety is encapsulated and calling anything can be a wild ride.

[insanitybit]

> 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.

[endospore]

> Zig does have invariants

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.

[insanitybit]

> Not these in particular. You are again ignoring the context.

What context? I just said afterwards that aliasing is not one of those cases.

> Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions:

Nope and your post wouldn't justify the statement. Not all UB leads to a reachable bug. The blog post doesn't say otherwise, and in fact it indicates exactly this (that UB can compile "correctly" one day and "incorrectly" the next). Check the errata on the post.

> Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".

No, I'm right other than l-unsound. Saying "but safe code that references unsafe code" doesn't change that.

> It's as hard as rewriting the codebase from ground up without reference

Not necessarily. At least multiple cases I've seen in the rewrite would be a matter of just moving `unsafe` from one spot to another and then placing the assertions at the caller.

This conversation is increasingly dumb. I've made my point repeatedly - moving to Rust means memory unsafety violations can be grepped for and that's not up for debate. You can say that that's not sufficient as a win for the project, I really am ambivalent.

[endospore]

> increasingly dumb

That's untrue. It has already been maximally dumb since your first comment with the various logical fallacies you managed to carry out in a single sentence. The only reason I'm still making my replies is that you are making so many false claims that may mislead someone else.

https://doc.rust-lang.org/nomicon/working-with-unsafe.html

I'm not even trying to prove any point since the beginning. Can't do that when you have a different definition of bug from others.

Please if you are going to reply to this ever again try stop making any claims. Otherwise I'm afraid that it will continue into infinity.

[insanitybit]

My claim is that you can grep for memory safety bugs in rust and you can't in zig, therefor trading memory unsafe zig bugs for memory unsafe rust bugs is a good trade. This has been my claim, it continues to be my claim. Linking to the nomicon won't change anything just like linking to the other blog post changed nothing (and you literally misunderstood the other blog post, and I even pointed you to the errata of that post).