New @bitCast Semantics and LLVM Backend Improvements
28 points by rcalixte
28 points by rcalixte
logical bit representation (which is endian-agnostic)
What the article describes is straightforwardly little-endian, without any support for big-endian bit order or byte order.
i think what they mean by "endian-agnostic" is that the behavior doesnt change between LE and BE architectures
Author here---yep, this is what I meant by "endian-agnostic". Any system like this does of course need to decide on some ordering for bits, and LSB-first is more consistent with the rest of Zig's design (and I might be so bold as to argue is just usually better!), so that's what we used.
Even if you want to argue we made the worse choice (which I don't think many really would in 2026!), most affected uses of @bitCast are in fact trying to write code which doesn't depend on the target endian, and were previously checking the target endian before or after the @bitCast operation to shuffle things around on BE or LE. Such code now doesn't need to be conditional on the native endian---if it wants the "little endian" behavior it just does the @bitCast, if it wants the "big endian" behavior it always needs a @byteSwap or something.
New devlog entry from June 25, 2026 about the new @bitCast semantics and LLVM backend improvements merged in a recent pull request.
This is neat! It does make me wonder how much code out there does something like the following that will suddenly be broken on rarely-tested big endian targets as a result though (apologies for the non-Zig pseudocode):
if target_is_little_endian {
my_int = @bitCast(my_array);
} else {
my_int = @bitCast([my_array[1], my_array[0]]);
}
I've been thinking about this too, but at the end of the day, delaying the inevitable will only make this problem worse. I don't expect this to be a big issue in practice though, since only a small fraction of @bitCast usages are actually affected by this change---of the thousands of @bitCasts in the Zig repository, I had to change... um, I didn't actually count, but I think it was well under 100.
To be honest, I also don't think most Zig users were actually familiar with the behavior of @bitCast when converting between arrays/vectors and scalars, so there's probably a lot of code in the wild which previously would have only worked on LE (because it was only tested on the author's system) and will now work everywhere :P