#PB_Compiler constants for Endianness

[benubi]

#PB_Compiler_IsBigEndian
#PB_Compiler_IsLittleEndian

Would be great additions for portability/interoperability. I just found out ARM64 and others from the family use little endian per default, but can also switch. I thought mistakenly it would always be big endian.

[r-i-v-e-r]

Big endian AArch64 is rare: iOS, Android, Windows, macOS, and most Linux distros run in LE mode on AArch64 hardware. AFAIK, BE is primarily useful for maximising performance of networking code (albeit this is serious min-maxing), but is otherwise mostly a hassle.

Given there's no big endian PureBasic Arm compiler build, we'd need one of those before such constants become useful, and it'd be extremely niche.

[benubi]

Then I was mistaken. I thought that some Mac versions (motorolla and PowerPC) might use Big Endian, and I believed at first the raspberry ARM would be BE. If I understand that correctly there is no big endian PB compiler around, yet?

I've seen "mixed endianness" in some articles, this was concerning GUID's in partition tables (the new types). I wondered what that meant but I suppose that a GUID is or should be a 16 bytes octet stream with "no endianness" per se (that's how I would handle it).

I believe the iso format that CD-ROM/DVD's use is also dual endianness, with addresses+offsets written in both endian versions but I digress.

Thank you for the answer!

[NicTheQuick]

Yes, there is a difference between endianess in memory during runtime and in written data in files or block devices like the partition tables you mentioned.