4 ms·
>Seriously, there's zero reason why endianness should matter in code How about wanting to share binary blobs between architectures without spending the effort
by jayd16 5y ago
>Seriously, there's zero reason why endianness should matter in code
How about wanting to share binary blobs between architectures without spending the effort to marshal things.
- yjftsjthsd-h 5y agoHow would binary blobs work on a different architecture regardless of endian-ness?
- zdw 5y agohtonl and ntohl would like a word.
- yjftsjthsd-h 5y agoYou mean https://linux.die.net/man/3/htonl https://linux.die.net/man/3/htonl ? What does that have to do with executing binaries on another architecture?
- nonesuchluck 5y agoBinary doesn't imply executable. A NumPy array is a binary blob.
- klodolph 5y agoYour binary blobs are structures with fixed-size primitives and a known layout, on ABIs with manageable structure packing rules: struct my_data { uint32_t x; uint16_t y; }; You can transmit data structures like this over the network with write(), if you want. You can say, “sizeof(my_data) == 8” and just refuse to support systems where this is not true. On the other end, you can obj.x = swap32(obj.x); obj.y = swap16(obj.y); where necessary, or avoid the swap if both peers have the same endian. Keep in mind that this is illustrative. Not trying to describe the details of how you would design a system from a higher level. Note that you’re not making any attempt to support all architectures, here. You can restrict yourself to byte-oriented architectures with the normal 8, 16, 32, and 64 bit integer types that have no stricter than natural alignment. That covers a useful, broad range of architectures. Depending on whether you care about architectures like M68k where uint32_t does not have natural alignment, you can manually pad out structures.