4 ms·

IBM zSeries runs Linux in big-endian mode and is still a mainstream product. If your code doesn’t work on big-endian, it’s usually poorly designed.

LegionMammal978 4y ago
Eh, I think it's a stretch to say that any possible dependency on little-endian can be rounded down to "poor design". If you're operating with a format or protocol that's unconditionally little-endian, then it takes strictly less work to operate on the data structures in place, or on direct bitwise copies of the data structures, rather than conditionally transforming the values to native-endian, operating on them, and conditionally transforming them back to little-endian. You can argue that everyone's code ought to take the longer route due to the existence of big-endian systems, but that's what this blog post is arguing against.
pm215 4y ago
Depending on what your code is doing, even if there are good endian-agnostic abstractions, endianness bugs are still likely to slip in from time to time unless you're defending against them by having your CI run on a big-endian platform. QEMU does this, and although CI-fails-on-BE is rare, it happens often enough that I wouldn't want to lose the coverage. (On the theme of the original article, IBM actively support this by giving us CI resource via the IBM LinuxONE Community Cloud machines, as well as being active in upstream development.)
cesarb 4y ago
> > 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.
- matja 4y ago
  > but how would one get access to an IBM zSeries? qemu-system-s390x - I run Linux in it for some automatic tests, finds some funny bugs occasionally.
  - rbanffy 4y ago
    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.
CJefferson 4y ago
Any code which cares about splitting ints, pointers or floats into individual bytes, or doing network traffic, will have to care about endianness. 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.
- johnklos 4y ago
  Or you could set up a Raspberry Pi with NetBSD/aarch64eb and just let it take its time.
IshKebab 4y ago
Poorly designed... or you don't want to have to think about Endianness just to support some weird niche architecture that only a handful of enormous corporations use? 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.

LegionMammal978 4y ago

Eh, I think it's a stretch to say that any possible dependency on little-endian can be rounded down to "poor design". If you're operating with a format or protocol that's unconditionally little-endian, then it takes strictly less work to operate on the data structures in place, or on direct bitwise copies of the data structures, rather than conditionally transforming the values to native-endian, operating on them, and conditionally transforming them back to little-endian. You can argue that everyone's code ought to take the longer route due to the existence of big-endian systems, but that's what this blog post is arguing against.

pm215 4y ago

Depending on what your code is doing, even if there are good endian-agnostic abstractions, endianness bugs are still likely to slip in from time to time unless you're defending against them by having your CI run on a big-endian platform. QEMU does this, and although CI-fails-on-BE is rare, it happens often enough that I wouldn't want to lose the coverage. (On the theme of the original article, IBM actively support this by giving us CI resource via the IBM LinuxONE Community Cloud machines, as well as being active in upstream development.)

cesarb 4y ago

> > 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.

matja 4y ago
> but how would one get access to an IBM zSeries? qemu-system-s390x - I run Linux in it for some automatic tests, finds some funny bugs occasionally.
- rbanffy 4y ago
  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.

CJefferson 4y ago

Any code which cares about splitting ints, pointers or floats into individual bytes, or doing network traffic, will have to care about endianness. 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.

johnklos 4y ago
Or you could set up a Raspberry Pi with NetBSD/aarch64eb and just let it take its time.

IshKebab 4y ago

Poorly designed... or you don't want to have to think about Endianness just to support some weird niche architecture that only a handful of enormous corporations use? 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.