> > I've been trying to officially mark some open source software I work on as not supporting big endian. We don't test it, and I think it's very likely there are some subtle bugs.
> 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.
Also an option on Travis CI. Another option is getting Hercules, which can emulate a 390x, but, IIRC, falls short on some post z14 features more recent Linuxes rely upon. If you need time on an actual machine, there is the LinuxONE community cloud (Linux under z/VM) and IBM provides hardened (and expensive for 24x7 operation) Linux on Z instances (under KVM).
The IBM mainframe developer relations team is unusually friendly and approachable as well.
> 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.