nvme0n1p1
Born on February 14, 2026•309 Karma
"My patch got rejected because I was honest"
"My girlfriend broke up with me because I was honest"
https://www.youtube.com/shorts/Nx0r-_DuDek
I encourage the author to do a bit more self-reflection.
https://ziglang.org/documentation/master/std/#std.bit_set.St...
Sometimes it's just more clear to work with integers than other representations. Most situations with a state space of N bits have meaningful integer representations, where arithmetic functions on those representations are also meaningful.
For example, CRCs can be written as the remainder from long division of the message by the polynomial. Defining nontrivial cyclic permutations is also much more straightforward as functions on integers than on bitsets.
I was talking about GP's u729, which is 9*9*9, the state space of a sudoku board. Can you come up with a situation where dividing that number by anything is meaningful?
If I had to steel-man the idea, I'm pretty sure the integer-based solution has better codegen with many kinds of sparse, comptime-known masks. I think you're right though, StaticBitSet looks better.
> Converts a pointer of one type to a pointer of another type. [1]
[1] https://ziglang.org/documentation/master/#toc-ptrCast
So it is not the same.
You could use it to define a function that implements bitCast. Which defeats the purpose of having any @bitCast intrinsic instead of using @mempcy for everything
> You could use it to define a function that implements bitCast. Which defeats the purpose of having any @bitCast intrinsic
Yes, and this is one reason @bitCast was changed to have different semantics that are not trivially achieved with @ptrCast.
It is significantly worse to take address and deref afterwards.
You have to do something like:
@as(const u32, @ptrCast(&x)).
instead of just
@bitCast(x)
> Yes, and this is one reason @bitCast was changed to have different semantics that are not trivially achieved with @ptrCast.
This makes sense except breaking existing code that properly handled endianness by doing a conditional @byteSwap. And what you end up with is a more complicated intrinsic compared to something that reinterprets values with same layout size
Before Zig hits 1.0, users should expect language changes. Has anyone claimed otherwise?
If you need the old thing often enough, you can write a wrapper for it. It's a trivial one-liner, as you've shown.
> It is significantly worse to take address and deref afterwards.
How are you measuring worse? Because my understanding from the article is that's exactly the behavior @bitCast used to have. So, instead of worse, it'd be exactly the same?
If you mean it's simply more things that you have to type... You're describing a core language feature as "worse". For all the builtins, some of them can help the compiler emit better code, but can for some doesn't mean will for all. As an example
const thing: f64 = @floatFromInt(int_ish);
const result = thing + other_float;
return @intFromFloat(result);
And, yes having already made that exact mistake... I now write better code from the start because there's no way I'm gonna ruin all my beautiful code with a bunch of ugly, annoying, hard to read, casts.
I used to complain about unused variable errors, unhandled enum branch, var unmodified (hint: use const) errors, hell even result ignored or error ignored when I'm trying to test some unrelated single line of code. But now that I'm used to them, I emit better code without thinking. It's made me a better programmer. Is it annoying? abso-fucking-lutely but I'm better now than I used to be, so: worth it; and: thankyou sir can I have another. :D
Since you dodged the question, I guess your real answer is "no, people never did this" and therefore "yes, this is AI slop"
Sure there is. The simplest possible model that says "I don't know" 100% of the time would hallucinate less than Fable 5. Scaling up to more useful models, it's just a matter of tuning false negatives vs false positives.
Btw if you're running an OS that's never had a malware incident, please, tell us!
...is essentially impossible to pull off against commercial operating systems, because their core components are all written in-house by staff with photo ID badges, details with HR, tax returns filed with the government, and a cubicle that makes sure that they're locals and not some faceless anonymous hacker identifiable by nothing other than a throwaway faked email address!
I get that there was a lot of "stigma" about open source, the world largely forgot about it, but... actually, in this sense of allowing anonymous contributions it remains a very real risk.
"Jia Tan" was almost certainly a paid professional hacker working for a nation-state actor. Their "helpful contributions" to XZ utils was nowhere near a full-time effort. They certainly had "other irons on the fire", most probably in the Linux kernel or immediately adjacent to it.
He's probably not the only one doing this kind of "work".
For all you know, Linux has more remote exploits purposefully baked into it than Windows has security bugs inadvertently left in it... and don't forget Linux has bugs leading to security vulnerabilities too!
A rough count of "named" CVE 10.0 score (or close to it) vulns in the last 5 years:
7 for Microsoft: ProxyLogon, ProxyShell, ProxyNotShell, LDAPNightmare, PrintNightmare, noPac, Follina
10 for Linux: XZ Utils, regreSSHion, Leaky Vessels, Copy Fail, PwnKit, Dirty Pipe, Looney Tunables, GameOver(lay), Baron Samedit, Sequoia
As for "Linux", you'd need to specify the distro and environment, because Linux systems can be very different from one another. Your XZ example for instance didn't even affect most enterprise distros (like RHEL). regreSSHion didn't affect any musl libc distros like Alpine, but other systems would've also been unaffected had you set your LoginGraceTime to 0, which any sysadmin worth their salt would've done so. Leaky Vessels fails on SELinux enforcing distros (RHEL, Fedora etc) and sandboxed environments. I could go on, but you get the picture. Comparing the number of "Linux" vulnerabilities to Windows is completely pointless.
the ransomware campaigns would have happened on any OS enterprises use, because they were not security flaws in the OS