That's where big endian is now. All the BE architectures are dying or dead. No big endian system will ever be popular again. It's time for big endian to be consigned to the dustbin of history.
And, especially what most people call big-endian, which is a bastardized mixed-endian mess of most significant byte is zero, while least significant bit is likewise zero.
In the 1980s at AT&T Bell Labs, I had to program 3B20 computers to process the phone network's data. 3B20s used the weird byte order 1324 (maybe it was 2413) and I had to tweak the network protocols to start packets with a BOM (byte order mark) (as the various switches that sent data didn't define endianess), then swap bytes accordingly.
Lesson learned was Never Ignore Endian issues.
As for networking, Ethernet is particularly fun: least significant bit first, most significant byte first for multi-byte fields, with a 32-bit CRC calculated for a frame of length k by treating bit n of the frame as the coefficient of the (k - 1 - n)th order term of a (k - 1)th order polynomial, and sending the coefficients of the resulting 31st order polynomial highest-order coefficient first.
[1] https://vtda.org/docs/computing/AT&T/3B2/3b2_Assembly_Lang_P...
I was in charge of the firmware for a modem. I had written the V.42 error correction, and we contracted out the addition of the MNP correction protocol. They used the same CRC.
The Indian (only important because of their cultural emphasis on book learning) subcontractor found my CRC function, decided it didn't quite look like the academic version they were expecting, and added code to swap it around and use it for MNP, thus making it wrong.
When I pointed out it was wrong, they claimed they had tested it. By having one of our modems talk to another one of our modems. Sheesh.
This is an excellent lesson for data transport protocols and file formats.
> I had to tweak the network protocols to start packets with a BOM (byte order mark) (as the various switches that sent data didn't define endianess), then swap bytes accordingly.
(A similar thing happened to me with the Python switch from 2 to 3. Strings all became unicode-encoded, and it's too difficult to add the b sigil in front of every string in a large codebase, so I simply ensured that at the very few places that data was transported to or from files, all the strings were properly converted to what the internal process expected.)
But, as many other commenters have rightly noted, big-endian CPUs are going the way of CPUs with 18 bit bytes that use ones-complement arithmetic, so unless you have a real need to run your program on a dinosaur, you can safely forget about CPU endianness issues.
[1] https://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22...
[2] https://www.ibm.com/docs/en/SSQ2R2_15.0.0/com.ibm.tpf.toolki...
Yes, if I hadn't known about that, I probably wouldn't have written "most."
> While I have a strong personal preference for little endian
Despite the porportedly even-handed treatment given in the seminal paper:
https://www.rfc-editor.org/ien/ien137.txt
That paper was obviously a product of motivated reasoning. And motivated reasoning in the hands of an intelligent and articulate person is always dangerous.
(Today, in the public sphere, we are seeing successful motivated reasoning by people who are much less intelligent and articulate, but that is a completely separate issue.)
The primary benefit (from observation of past arguments) that big-endian has is when you are dumping data and looking at a sequence of bytes, and don't want to mentally swap them around.
But that itself begs the question. If you are so keen on big-end first, then why does your dump start at the small end of memory?
Overall this seems like a pretty weird choice on a planet where the vast majority of text is written from left to right and only numbers are written right to left. Especially since endianness only affects byte order but not bit order, as you said.
But if you really believe the left side is bigger, why do you put the smaller memory address on the left side of your dump?
Cries in 68k nostalgia
Most existing CPUs, have instructions to load and store memory data of various sizes into registers, while reversing the byte order.
So programs that work with big-endian data typically differ from those working with little-endian data just by replacing the load and store instructions.
Therefore you should have types like int16, int32, int64, int16_be, int32_be, int64_be, for little-endian integers and big-endian integers and the compiler should generate the appropriate code.
At least in the languages with user-defined data types and overloadable operators and functions, like C++, you can define these yourself, when the language does not provide them, instead of using ugly workarounds like htonl and the like, which can be very inefficient if the compiler is not clever enough to optimize them away.
I wouldn't want to maintain those types. The maintainer would either have to implement all of the arithmetic operations or assume that your users would try to hack their way to arithmetic. But really, you shouldn't ever do arithmetic with non-native endianness anyway.
Instead, define all your interfaces to work with native endianness integers and just do byte swapping at the serialization boundaries.
Network protocols and file formats still need a defined byte order, and the first time your code talks to hardware or reads old data, little-endian assumptions leak all over the place. Ignoring portability buys you a pile of vendor-specific hacks later, because your team will meet those 'irrelevant' platforms in appliances, embedded boxes, or somebody else's DB import path long before a sales rep waves a support contract at you.