> ignoring the fact that it was an intermediate step. They are going to release the "intermediate step" with all its issues as v1.4. I think that says a lot about which party is ignoring facts. (hint: not me, not you,…
Yes, they have introduced (at least) several times more memory safety issues by violating the rust specific rules. Check how most of their unsafe blocks are unsound and worse, how many are straight up incorrect with a…
> 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…
> 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…
Oh it's so nice of you when I've spent the bottom half of my comment explaining how you cannot grep for most of them in this BAD codebase. Please READ.
Lol we have reached the depth limit so I'm casually posting here instead. Since 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…
Instead of "possible" undefined behaviors, potential bugs, the samples I've randomly picked are all actual undefined behaviors, real bugs. Hence statistically. > pointer aliasing is undefined behavior in both languages…
Yes you are. Either that or you are too distracted to read or you wouldn't be repeating > ~2X potential at this point. That's what I've found in 10 minutes. And they are (mostly) actual bugs that I've take extra time to…
> made grep'able That's not the correct understanding. These are specifically the ones that were not bugs in Zig. They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code…
Can't assume good faith in you at this point but I'll explain it. - They've written two articles, one by claude doing the migration another by the human behind it, neither acknowledge these problems. Nor does the…
Measurably yes. They claim that 128 problems from the zig version was fixed, so I grepped for two known categories of UBs and unsoundness unique to unsafe Rust and found 237.
Look a few more till you find absolutely bs SAFETY comments marked on immediate UBs. They are everywhere.
Well the rewrite has newly introduced many immediate and critical safety (as in Rust sense) problems. It's clear and obvious if you read the code knowing the basic rules of unsafe Rust. And don't be surprised if it…
Ha. You'll be surprised when you find out how much new problems were created in the code base precisely because the author's (not sure if it's still the right word here, they barely involved) lack of knowledge of Rust.…
No. They introduced quite a few aliasing issues that result in immediate UB in Rust but are allowed in Zig. I skimmed over the unsafe blocks with rg for ten minutes and spotted like 3 cases and these wouldn't exist in…
Calling it as working is a bit of an exaggeration. Looked at the code for a few minutes I'd expect it to crash and burn if they ever dare to turn the optimization on.
> emulate unsafe C pointer semantics with unsafe Rust Yes and that would be safer than the current slop translation, because c2rust does these ugly things exactly to avoid introducing new issues with the more strict…
> I have debug symbols turned on, which activated dev dependencies Nope that doesn't happen. It's not compiled into your binary if it's a dev or build dependency. Cargo may have downloaded the crate source according to…
Makes me wonder why zig announced the strict LLM rule recently. I'm afraid one reason could be that zig doesn't want to accept code from the bun fork in the first place (because of LLM usage, deviation and other reasons)
> the OS is inconsistent/unclear about what scan codes are required to do things. Both that, and there's an internal list that allows only Apple's (plus a few makers' like Logitech and Keychron) keyboard to _send_ the…
[dead]
> ignoring the fact that it was an intermediate step. They are going to release the "intermediate step" with all its issues as v1.4. I think that says a lot about which party is ignoring facts. (hint: not me, not you,…
Yes, they have introduced (at least) several times more memory safety issues by violating the rust specific rules. Check how most of their unsafe blocks are unsound and worse, how many are straight up incorrect with a…
> 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…
> 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…
Oh it's so nice of you when I've spent the bottom half of my comment explaining how you cannot grep for most of them in this BAD codebase. Please READ.
Lol we have reached the depth limit so I'm casually posting here instead. Since 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…
Instead of "possible" undefined behaviors, potential bugs, the samples I've randomly picked are all actual undefined behaviors, real bugs. Hence statistically. > pointer aliasing is undefined behavior in both languages…
Yes you are. Either that or you are too distracted to read or you wouldn't be repeating > ~2X potential at this point. That's what I've found in 10 minutes. And they are (mostly) actual bugs that I've take extra time to…
> made grep'able That's not the correct understanding. These are specifically the ones that were not bugs in Zig. They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code…
Can't assume good faith in you at this point but I'll explain it. - They've written two articles, one by claude doing the migration another by the human behind it, neither acknowledge these problems. Nor does the…
Measurably yes. They claim that 128 problems from the zig version was fixed, so I grepped for two known categories of UBs and unsoundness unique to unsafe Rust and found 237.
Look a few more till you find absolutely bs SAFETY comments marked on immediate UBs. They are everywhere.
Well the rewrite has newly introduced many immediate and critical safety (as in Rust sense) problems. It's clear and obvious if you read the code knowing the basic rules of unsafe Rust. And don't be surprised if it…
Ha. You'll be surprised when you find out how much new problems were created in the code base precisely because the author's (not sure if it's still the right word here, they barely involved) lack of knowledge of Rust.…
No. They introduced quite a few aliasing issues that result in immediate UB in Rust but are allowed in Zig. I skimmed over the unsafe blocks with rg for ten minutes and spotted like 3 cases and these wouldn't exist in…
Calling it as working is a bit of an exaggeration. Looked at the code for a few minutes I'd expect it to crash and burn if they ever dare to turn the optimization on.
> emulate unsafe C pointer semantics with unsafe Rust Yes and that would be safer than the current slop translation, because c2rust does these ugly things exactly to avoid introducing new issues with the more strict…
> I have debug symbols turned on, which activated dev dependencies Nope that doesn't happen. It's not compiled into your binary if it's a dev or build dependency. Cargo may have downloaded the crate source according to…
Makes me wonder why zig announced the strict LLM rule recently. I'm afraid one reason could be that zig doesn't want to accept code from the bun fork in the first place (because of LLM usage, deviation and other reasons)
> the OS is inconsistent/unclear about what scan codes are required to do things. Both that, and there's an internal list that allows only Apple's (plus a few makers' like Logitech and Keychron) keyboard to _send_ the…
[dead]