Sometimes someone will ask for support, but (unsurprisingly, I don't blame them) they don't want to put the work into testing up to the standard we achieve on ARM and x64.
If your code doesn’t work on big-endian, it’s usually poorly designed.
> IBM zSeries runs Linux in big-endian mode and is still a mainstream product.
For most hobbyist open source software developers, it's a niche product in practice. I can easily test on 32-bit and 64-bit x86 (most desktops and laptops can run it natively); I can easily test on 32-bit and 64-bit ARM (a Raspberry Pi 3B or newer is a common enough device, and using Termux on a phone is also an option); but how would one get access to an IBM zSeries?
> If your code doesn’t work on big-endian, it’s usually poorly designed.
The parent comment mentioned "subtle bugs". It's not hard to accidentally introduce byte order dependencies; one simple example (though from the big endian side) would be forgetting to use "htons" on a port number. Since more and more protocols and file formats are natively little endian nowadays, it's easy to miss a conversion between "little endian" and "native endian", since it will still work perfectly on little endian architectures.
qemu-system-s390x - I run Linux in it for some automatic tests, finds some funny bugs occasionally.
The IBM mainframe developer relations team is unusually friendly and approachable as well.
Now, there are of course ways to handle this, but in C and C++ it's easy to make mistakes, and it's hard to test.
I'd be happy supporting big-endian if someone wants to buy me a z series equivalent in power to a mid-level AMD laptop, and also get GitHub to add them as a standard target for GitHub actions.
I really don't think there's anything wrong with assuming little endian in this age. It's like assuming 8 bit bytes, or 2s complement signed numbers.