Hacker News new | ask | show | jobs
by endospore 18 days ago
> 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.

1 comments

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

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

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