Determining endianness at compile time [duplicate]

To answer the original question of a compile-time check, there's no standardized way to do it that will work across all existing and all future compilers, because none of the existing C, C++, and POSIX standards define macros for detecting endianness.

But, if you're willing to limit yourself to some known set of compilers, you can look up each of those compilers' documentations to find out which predefined macros (if any) they use to define endianness. This page lists several macros you can look for, so here's some code which would work for those:

#if defined(__BYTE_ORDER) && __BYTE_ORDER == __BIG_ENDIAN || \    defined(__BIG_ENDIAN__) || \    defined(__ARMEB__) || \    defined(__THUMBEB__) || \    defined(__AARCH64EB__) || \    defined(_MIBSEB) || defined(__MIBSEB) || defined(__MIBSEB__)// It's a big-endian target architecture#elif defined(__BYTE_ORDER) && __BYTE_ORDER == __LITTLE_ENDIAN || \    defined(__LITTLE_ENDIAN__) || \    defined(__ARMEL__) || \    defined(__THUMBEL__) || \    defined(__AARCH64EL__) || \    defined(_MIPSEL) || defined(__MIPSEL) || defined(__MIPSEL__)// It's a little-endian target architecture#else#error "I don't know what architecture this is!"#endif

If you can't find what predefined macros your compiler uses from its documentation, you can also try coercing it to spit out its full list of predefined macros and guess from there what will work (look for anything with ENDIAN, ORDER, or the processor architecture name in it). This page lists a number of methods for doing that in different compilers:

Compiler                   C macros                         C++ macrosClang/LLVM                 clang -dM -E -x c /dev/null      clang++ -dM -E -x c++ /dev/nullGNU GCC/G++                gcc   -dM -E -x c /dev/null      g++     -dM -E -x c++ /dev/nullHewlett-Packard C/aC++     cc    -dM -E -x c /dev/null      aCC     -dM -E -x c++ /dev/nullIBM XL C/C++               xlc   -qshowmacros -E /dev/null  xlc++   -qshowmacros -E /dev/nullIntel ICC/ICPC             icc   -dM -E -x c /dev/null      icpc    -dM -E -x c++ /dev/nullMicrosoft Visual Studio (none)                              (none)Oracle Solaris Studio      cc    -xdumpmacros -E /dev/null  CC      -xdumpmacros -E /dev/nullPortland Group PGCC/PGCPP  pgcc  -dM -E                     (none)

Finally, to round it out, the Microsoft Visual C/C++ compilers are the odd ones out and don't have any of the above. Fortunately, they have documented their predefined macros here, and you can use the target processor architecture to infer the endianness. While all of the currently supported processors in Windows are little-endian (_M_IX86, _M_X64, _M_IA64, and _M_ARM are little-endian), some historically supported processors like the PowerPC (_M_PPC) were big-endian. But more relevantly, the Xbox 360 is a big-endian PowerPC machine, so if you're writing a cross-platform library header, it can't hurt to check for _M_PPC.

This is for compile time checking

You could use information from the boost header file endian.hpp, which covers many platforms.

edit for runtime checking

bool isLittleEndian(){    short int number = 0x1;    char *numPtr = (char*)&number;    return (numPtr[0] == 1);}

Create an integer, and read its first byte (least significant byte). If that byte is 1, then the system is little endian, otherwise it's big endian.

edit Thinking about it

Yes you could run into a potential issue in some platforms (can't think of any) where sizeof(char) == sizeof(short int). You could use fixed width multi-byte integral types available in <stdint.h>, or if your platform doesn't have it, again you could adapt a boost header for your use: stdint.hpp

With C99, you can perform the check as:

#define I_AM_LITTLE (((union { unsigned x; unsigned char c; }){1}).c)

Conditionals like if (I_AM_LITTLE) will be evaluated at compile-time and allow the compiler to optimize out whole blocks.

I don't have the reference right off for whether this is strictly speaking a constant expression in C99 (which would allow it to be used in initializers for static-storage-duration data), but if not, it's the next best thing.