2 ms·
> any RFC that defines a protocol including binary data will generally go with big-endian numbers I'm not sure this is true. And if it is true it really should
by forrestthewoods 2y ago
> any RFC that defines a protocol including binary data will generally go with big-endian numbers
I'm not sure this is true. And if it is true it really shouldn't be. There are effectively no modern big endian CPUs. If designing a new protocol there is, afaict, zero benefit to serializing anything as big endian.
It's unfortunate that TCP headers and networking are big endian. It's a historical artifact.
Converting data to/from BE is a waste. I've designed and implemented a variety of simple communication protocols. They all define the wire format to be LE. Works great, zero issues, zero regrets.
- classichasclass 2y ago> There are effectively no modern big endian CPUs. POWER9, Power10 and s390x/Telum/etc. all say hi. The first two in particular have a little endian mode and most Linuces run them little, but they all can run big, and on z/OS, AIX and IBM i, must do so. I imagine you'll say effectively no one cares about them, but they do exist, are used in shipping systems you can buy today, and are fully supported.
- forrestthewoods 2y agoYeah those are a teeny tiny fraction of CPUs on the market. Little Endian should be the default and the rare big endian CPU gets to run the slow path. Almost no code anyone here will write will run on those chips. It’s not something almost any programmer needs to worry about. And those that do can easily add support where it’s necessary. The point is that big endian is an extreme outlier.