7

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?

Anne Quinn
  • 12,609
  • 8
  • 54
  • 101
  • 7
    Endianness is decided by the *hardware*, more specifically the CPU used. – Some programmer dude Jul 07 '16 at 15:50
  • 1
    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? – Marc B Jul 07 '16 at 15:51
  • Related: http://stackoverflow.com/questions/4239993/determining-endianness-at-compile-time – alk Jul 07 '16 at 15:52
  • 3
    "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. – Pierre Emmanuel Lallemant Jul 07 '16 at 15:55
  • 1
    you can assume the little-endian will work for the majority of the targets. – Pierre Emmanuel Lallemant Jul 07 '16 at 15:56
  • 2
    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) – Pierre Emmanuel Lallemant Jul 07 '16 at 15:56
  • @pierre - that was my thought process, easier to check if it breaks in the rare case it does, than to code for different cases – Anne Quinn Jul 07 '16 at 15:57

3 Answers3

6

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
dbush
  • 205,898
  • 23
  • 218
  • 273
2

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

Jean-Baptiste Yunès
  • 34,548
  • 4
  • 48
  • 69
1

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).

Community
  • 1
  • 1
πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190
  • 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. – Rudy Velthuis Jul 07 '16 at 15:55
  • 1
    @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()`, it would be impossible to load such "save" on the other platform. The `hton()`/etc used for all import/export of data will ensure, that data going in/out from app have fixed endianness. – Ped7g Jul 07 '16 at 16:27
  • 1
    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. – PC Luddite Jul 07 '16 at 17:17
  • 1
    @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? – πάντα ῥεῖ Jul 07 '16 at 17:19
  • @πάνταῥεῖ Yes, I have, but the platform you are cross compiling for has already "decided" its endianness. – PC Luddite Jul 07 '16 at 17:24
  • @Ped7g: I know that these are in fact two different programs in one binary. I even wrote that. – Rudy Velthuis Jul 07 '16 at 18:48
  • "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. – Jean-Baptiste Yunès Jul 07 '16 at 19:21