6 ms·
That sounds like a problem to deal with as part of your paid IBM s390x porting contract. I guess my point is: why deal with this before IBM is paying you? No ot
by electroly 6mo ago
That sounds like a problem to deal with as part of your paid IBM s390x porting contract. I guess my point is: why deal with this before IBM is paying you? No other big endian platform matters, and s390x users are 100% large commercial customers. If IBM or one of their customers isn't paying you, there's nobody else who would need it. If IBM is paying you, you can test on a real z/VM that they provide. I see big endian as entirely their burden now; nobody else needs it. If they want it, they can pay for the work.
- Retr0id 6mo agoI value correct code for purely selfish reasons. The most likely person to try to run my code on a BE system is me.
- eesmith 6mo agoThere are a lot of odd (by modern standards) machines out there. You're also the most likely person to try to run your code on an 18 bit machine.
- fc417fc802 6mo agoIt might sound outrageous but I guard against this sort of thing. When I write utility code in C++ I generally include various static asserts about basic platform assumptions.
- junofan 6mo agoThis is much-appreciated. I’m hardly a Richard Stallman, but finding little incompatibilities after-the-fact is pretty irritating.
- eesmith 6mo agoTake a look at https://www.kermitproject.org/ckupdates.html https://www.kermitproject.org/ckupdates.html . These quotes come from the last few years: > [fixes] specific to VMS (a.k.a. OpenVMS), > For conformity with DECSYSTEM-20 Kermit ... > running on a real Sun3, compiled with a non-ANSII compiler (Sun cc 1.22) > this is fatal in HP-UX 10 with the bundled compiler > OpenWatcom 1.9 compiler > OS/2 builds > making sure that all functions are declared in both ANSI format and K&R format (so C-Kermit can built on both new and old computers) Oooooh! A clang complaint: 'Clang also complains about perfectly legal compound IF statements and/or complex IF conditions, and wants to have parens and/or brackets galore added for clarity. These statements were written by programmers who understood the rules of precedence of arithmetic and logical operators, and the code has been working correctly for decades.'
- jasomill 6mo agoBut wait, there's more! As of the fourth Beta, DECnet support has been re-enabled. To make LAT or CTERM connections you must have a licensed copy of Pathworks32 installed. SSH is now supported on 32bit ARM devices (Windows RT) for the first time REXX support has been extended to x86 systems running Windows XP or newer. This was previously an OS/2-only feature. No legacy telnet encryption (no longer useful, but may return in a future release anyway) For context: The first new Kermit release for Windows in TWENTY-TWO YEARS Yes, it's called Kermit 95 once again! K95 for short. 2025 is its 40th anniversary.
- classichasclass 6mo agoSo do I. I don't find that outrageous at all. Anyone trying to do the port to something unusual would appreciate the warning. Granted, I still work on a fair number of big endian systems even though my daily drivers (ppc64le, Apple silicon) are little.
- bear8642 6mo ago> daily drivers (ppc64le, Apple silicon) How come you're running ppc64le as a daily driver?
- CursedSilicon 6mo agoCameron is known to have a TALOS II machine
- eesmith 6mo agoThere's platform and there's platform. I assume a POSIX platform, so I don't need to check for CHAR_BIT. My code won't work on some DSP with 64-bit chars, and I don't care enough to write that check. Many of the tests I did back in the 1990s seem pointless now. Do you have checks for non-IEEE 754 math?
- shakna 6mo agoWell, last year clang did not define __STDC_IEC_559__, so assuming IEEE-754 math with most C compilers is a bad idea.
- eesmith 6mo agoDo you have checks for non-IEEE 754 math?
- shakna 6mo agoOkay, as the last wasn't obvious enough: C does not do IEEE 754 math. It is _all_ non-IEEE 754 math. That it isn't compliant is a compiler guarantee, in the current state of things. You may as well have an `assert(1)`.
- eesmith 6mo agoAnd as I wrote, "There's platform and there's platform." I don't support the full range of platforms that C supports. I assume 8 bit chars. I assume good hardware support for 754. I assume the compiler's documentation is correct when it says it map "double" to "binary64" and uses native operations. I assume if someone else compiles my code with non-754 flags, like fused multiply and add, then it's not a problem I need to worry about. For that matter, my code doesn't deal with NaNs or inf (other than input rejection tests) so I don't even need fully conformant 754.
- fc417fc802 6mo agoSo you don't test for it because your code doesn't use it. Which is fine, but says nothing about code which does depend on the relevant assumptions.
- Retr0id 6mo agoAlso, endian-correct code is usually semantically clearer. For example, if you're reading network-ordered bytes into an int, an unconditional endian swap (which will produce correct results on LE systems but not BE) is less clear than invoking a "network bytes to u32" helper.
- namibj 6mo agou32::from_be_bytes u32::from_le_bytes u32::from_ne_bytes the n stands for native
- kelnos 6mo agoI think that's a bit different than the argument being made. We should still always use htonl() and ntohl() etc. when dealing with protocols that use network byte order (a shame we're stuck dealing with that legacy). I think even if all big-endian machines magically disappeared tomorrow, we should still do that (instead of just unconditionally doing a byte-swap). But for everything else, it's fine to assume little-endian. You sound like some sort of purist, so sure, if you really want to be explicit and support both endiannesses in your software when needed, go for it. But as general advice to random programmers: don't bother.