The Byte Order Fiasco
justine.lol
The Byte Order Fiasco
1–10 of 378 posts
Re: The Byte Order Fiasco
#2It’s not every day you can write a blog post that calls out rob pike… ;)
Re: The Byte Order Fiasco
#3Byte order is one of the great unnecessary historical fuck ups in computing.
A similar one is that signedness of char is machine dependent. It's typically signed on Intel and unsigned on ARM.
Sigh!
Re: The Byte Order Fiasco
#4A while back I was on a project to port a satellite simulator from SPARC/Solaris to RHEL/x64. The compressed telemetry stream that came from the satellite needed to be in big endian (and that's what the ground station software expected), and the simulator needed to mimic the behavior.
This was not a problem for the old SPARC system, which naturally put everything in the correct order without any fuss, but one of the biggest sticking points in porting over to x64 was having to now manually pack all of that binary data. Using Ada, (what else!) of course.
Re: The Byte Order Fiasco
#5This problem is it’s own special horror in Canbus data. Between endianness and sign it’s a nightmare of en/decoding possibilities and the associated mistakes that come with that.
Re: The Byte Order Fiasco
#6Ubsan should default on. If people don't like it, then they should be made turn it off with a switch, so at least it's more likely to be run than not run. Could save a huge amount of time debugging when compilers or architecture changes. Without it, I'd say many a programmer would be caught by these subtleties in the standard. Coming from a HW background (Verilog) I'd more naturally default to masking and shifting when building up larger variables from smaller ones, but I can imagine many would not.
Re: The Byte Order Fiasco
#7Byte order is one of the great unnecessary historical fuck ups in computing. A similar one is that signedness of char is machine dependent. It's typically signed on Intel and unsigned on ARM. Sigh!
And which is the correct byte ordering, pray tell?
Re: The Byte Order Fiasco
#8If you can assume GCC or Clang then __builtin_bswap{16,32,64} functions are provided which will be considerably more efficient, less error-prone, and easier to use than anything you can homebrew.
Re: The Byte Order Fiasco
#9Byte order is one of the great unnecessary historical fuck ups in computing. A similar one is that signedness of char is machine dependent. It's typically signed on Intel and unsigned on ARM. Sigh!
The good thing is that Big Endian is pretty much irrelevant these days.
Of all the historically Big Endian architectures, s390x is indeed the only one left that has not switched to little endian.
Re: The Byte Order Fiasco
#10Byte order is one of the great unnecessary historical fuck ups in computing. A similar one is that signedness of char is machine dependent. It's typically signed on Intel and unsigned on ARM. Sigh!
And which is the correct byte ordering, pray tell?
Big Endian of course :-) However the one which has won is Little Endian. Even IBM admitted this when it switched the default in POWER 7 to little endian. s390x is the only significant architecture that is still big endian.