☭
@onfy The bit shifting should still work! I'm not sure how to explain why, but I'm pretty confident that it should work here. (Possibly for the same reason that you can write x = 0x1234; on a little endian CPU and it doesn't instead get assigned 0x4321, the number is treated independently from its storage in memory?)
However, something like this:
uint32_t x;
memcpy(&x, addr, 4);
would break on a big endian CPU, since it'd just verbatim copy the bytes from the addr into x and the bytes stored at addr are little endian regardless of your CPU and the numbers are big endian in memory on a big endian CPU
☭
@onfy If you want, I could test your code on a Big Endian PowerBook G4 once it's done?
☭
@onfy Correct
And the x = (addr[3] << 24) /* ... and so on */ is considered "you assign it that way"
☭
@onfy TBH I'm not feeling very good, either, and don't want to get up and go get my PowerBook that's on the bed right now and I can't SSH into right now
☭
@onfy Hmm... All the x86, whether 16, 32, or 64 bit, are all little endian. ARM might be one of those architectures that exist in both variants, not sure, but as far as I'm aware, all the evil rectangles and Raspberry Pi and such all run it in little endian, too. Don't know about RISC-V.
So I guess the kind of people who would run it in big endian would be those who still run SPARC, MIPS, or PowerPC in 2026, so not very many
@vaporeon_ @onfy my endian is huge, thank you very much.