Is endianness decided at compile time?

Question

I want to be lazy and write some code that will break if the endianness of the target machine is different from my own, for right now. But I would like to know when it breaks of course, so I can fix it if or when it becomes necessary.

Is the endianness of floats and integers a property of the compiled program, such that I can check it at compile time with an assertion somehow? Or would it be something I have to assert at runtime?

Hoover

Endianness is decided by the hardware, more specifically the CPU used. – Breastfeed

no. you need to know in advance what the endianess is. e.g. consider a pointer to an integer. what does that memory address of the pointer point to? the high byte or the low byte of that int? – Hawse

Related: #4240493 – Frizzle

"endianness of floats", not sure it works for floats. For integers yes, but 2 cpu with the same endianness can represent the float differently internally. – Skill

you can assume the little-endian will work for the majority of the targets. – Skill

And you can cross-compile to handle the other target, so even if you are under little endian hardware, you can produce executables to different targets (you won't be able to run it under your hardware, but you can do it from a single machine) – Skill

@pierre - that was my thought process, easier to check if it breaks in the rare case it does, than to code for different cases – Hoover

Answer 1

Yes, endianness is inherent to the machine in question and is known at compile time. Most OSs will have a #define set up somewhere to tell you what the endianness is.

On Linux in particular you can do the following:

#if __BYTE_ORDER == __LITTLE_ENDIAN
...
#elif __BYTE_ORDER == __BIG_ENDIAN
...
#elif __BYTE_ORDER == __PDP_ENDIAN
...
#else
...
#endif

Convict

1+ for a PDP... running Linux! :-) – Frizzle

A nice Linux answer. OS's do not set-up #define, the compiler does. Could improve and discuss differences in integer and FP endian. – Honorable

Answer 2

Some hardware provide both (PowerPC for example)... but in general there is a native mode. Anyway, a compile-time assertion is generally sufficient.

Gablet

Interesting fact, didn't know this. "Anyway, a compile-time assertion is generally sufficient." Id' probably rather try to write endianess transparent code, if I'm going to exchange data between machines in form of files, or over the network. – Avelinaaveline

@πάνταῥεῖ Maybe you should consider taking the "Of course it's decided at compile time" out of your answer? – Sternway

@πάνταῥεῖ OP said that he needs to brake endianess, he could have good reasons for. – Charlatan

@Jean-BaptisteYunès "But I would like to know when it breaks of course" I'm not convinced that's the correct approach. – Avelinaaveline

@LightnessRacesinOrbit I've tempered that statement a bit. – Avelinaaveline

Answer 3

Is the endianness of floats and integers a property of the compiled program, such that I can check it at compile time with an assertion somehow?

It's decided at compile time which machine code is generated. A program cannot be compiled to machine code, that works on completely different CPU architectures.

To check at runtime which endianess is used at your current hardware, there are several methods available.

Also see Determining endianness at compile time.

---

Instead of using assertions for assuming a particular endianess in your code, you should use techniques to make any data saved to files, or communicated over a network connection transparent regarding endianess.

One way to do so, is to specify only big endian data should be used, and the code uses the hton<x>(), ntoh<x>() family of functions to encode and decode the data (see also network byte order).

Advisable

Actually, there was a question about this a few days ago, under x86, and well, it is possible. Think of Mac programs that can run on x86 or PowerPC, etc. But these two programs in one executable each have their own endianness, and that is determined by the CPU/platform. – Nathannathanael

@RudyVelthuis: there is no program capable to run both on x86 and PowerPC. Those programs behaving like that have actually binaries for both CPUs in the executable file, and the OS decides which part of the "phat" executable to load and execute. So it's like running two different programs. If one of them would create "save file" with int without endianness guarding mechanism like suggested hton<x>(), it would be impossible to load such "save" on the other platform. The hton<x>()/etc used for all import/export of data will ensure, that data going in/out from app have fixed endianness. – Vaccine

Endianness is not decided at compile time. In fact, it's decided well before you even start up your favorite text editor and begin writing you program. – Coggins

@PCLuddite I don't get what you mean? The compiler picks up an endianess scheme and target architecture at the time you call it with the appropriate options accordingly. Did you ever hear about cross-compiling? – Avelinaaveline

@πάνταῥεῖ Yes, I have, but the platform you are cross compiling for has already "decided" its endianness. – Coggins

@Ped7g: I know that these are in fact two different programs in one binary. I even wrote that. – Nathannathanael

"completely different CPU architectures" you can have completely different architecture that are binary compatible. Architecture is not relevant (too general), instruction set architecture is more. – Charlatan