> When programming, it is still important to write code that runs correctly on systems with either byte order

I contend it's almost never important and almost nobody writing user software should bother with this. Certainly, people who didn't already know they needed big-endian should not start caring now because they read an article online. There are countless rare machines that your code doesn't run on--what's so special about big endian? The world is little endian now. Big endian chips aren't coming back. You are spending your own time on an effort that will never pay off. If big endian is really needed, IBM will pay you to write the s390x port and they will provide the machine.

▲

Retr0id 5 hours ago | parent | next [-]

> There are countless rare machines that your code doesn't run on--what's so special about big endian?

One difference is that when your endian-oblivious code runs on a BE system, it can be subtly wrong in a way that's hard to diagnose, which is a whole lot worse than not working at all.

▲

electroly 5 hours ago | parent | next [-]

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 4 hours ago | parent [-]

I value correct code for purely selfish reasons. The most likely person to try to run my code on a BE system is me.

▲

Retr0id 3 hours ago | parent | next [-]

Also, 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 28 minutes ago \| parent [-]
		u32::from_be_bytes u32::from_le_bytes u32::from_ne_bytes the n stands for native

▲

eesmith 4 hours ago | parent | prev [-]

There 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 3 hours ago | parent [-]

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

▲

classichasclass an hour ago | parent | next [-]

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

▲

peyton an hour ago | parent | prev | next [-]

This is much-appreciated. I’m hardly a Richard Stallman, but finding little incompatibilities after-the-fact is pretty irritating.

	▲	eesmith an hour ago \| parent [-]
		Take a look at 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.'

▲

eesmith an hour ago | parent | prev [-]

There'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?

▲

edflsafoiewq 2 hours ago | parent | prev [-]

Static-assert the machine is little endian.

▲

Retr0id 2 hours ago | parent [-]

Someone's LLM will comment out that line the moment it causes a build failure

	▲	thrtythreeforty 37 minutes ago \| parent \| next [-]
		Then they get to keep both pieces!
	▲	edflsafoiewq 2 hours ago \| parent \| prev [-]
		Oh brave new world, that has such arguments in it!

▲

CJefferson 4 hours ago | parent | prev [-]

You are correct, honestly, I couldn't disagree more with th article. At this point I can't imagine why it's important.

It's also increasingly hard to test. Particularly when you have large expensive testsuites which run incredibly slowly on this simulated machines.