Determining endianness at compile time [duplicate]

Question

Is there a safe, portable way to determine (during compile time) the endianness of the platform that my program is being compiled on? I'm writing in C.

[EDIT] Thanks for the answers, I decided to stick with the runtime solution!

Depress

might be your solution #2100831 to detect it runtime – Kalk

See my answer which should do it at compile-time, as long as you don't mind requiring (at least partial) C99 support in the compiler. – Spandau

Yes, the technique is demonstrated in this question. – Suffuse

Why do you need to know? If you need to write in a format that is readable by another system use htonl() and family to convert to network byte order and back. On one system this will be the null operation. – Forestaysail

What's wrong with just using #ifdef __LITTLE_ENDIAN__ etc ? – Warrigal

@Paul: Who says __LITTLE_ENDIAN__ is an indicator that the machine is little endian and not one of two macros (along with __BIG_ENDIAN__) which are possible values for __BYTE_ORDER__? You can't know. As soon as you start inspecting macro names that were reserved for the implementation, your're on the road to the dark world of UB. Good code never directly inspects macros beginning with _[A-Z_] but instead uses a configure script or similar to work out its environment then uses #include "config.h" and #ifdef HAVE_FOO etc. – Spandau

@LokiAstari: Why is it that whenever somebody asks a perfectly legit question, somebody comes along shouting "Don't do that" or "Why do you need to know that"? The world is much bigger than you can imagine, and there are no ARPA headers on a myriad of systems, because they have no such notion as a "network ". Especially on microconroller environments you do need to know endianess for portability abstraction, perferably at preprocessor time (which is even before compile time). – Ganny

@T-Bull: Exactly becuase the world is more complex then you can imagine. Because sometime they are seeking a solution to a problem that does not need to be answered if you look at it from a different point of view. Asking to understand why they need to know something may help us understand the actual problem. We may find out that the question they ask is perfectly good for the situation they are trying to solve or alternatively we may find there are better ways of trying to solve the underlying problem. It is best never to assume anything. – Forestaysail

@LokiAstari: Well yeah, I understand your point of view, and even agree to the extent that there are many such questions where the questioner obviously lacks orientation so much that the question makes no sense at all. However, there're are also many replies (not answers) to perfectly valid questions which boil down to a stupid "Don't do that!" without any reasoning, and it appears I have a history of attracting such replies. At the least, I have the strong impression that SO is full of such people. Maybe addressing my comment to you was wrong, but with regard to SO, this /is/ a problem. – Ganny

Answer 1

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

Biffin

This does not answer the question; it's a runtime check, not a compiletime check. – Spandau

@R. The sentence at the top is about endian.hpp which would allow you to do compile time checks via macro checks. – Biffin

Nod. By the way, if sizeof(char)==sizeof(short), then uint8_t cannot exist on the implementation. C99 requires uint8_t to have no padding and be exactly 8 bits, and also defines the representation of types in terms of char/bytes, so uint8_t can only exist if CHAR_BIT==8. But then short could not hold the required minimum range. :-) – Spandau

reading the documentation of endian.hpp: it's not compile time checking the endianess. it's extracting the endianess from headers, if they're exposed. so it's not guaranteed to work. – Inclination

Relying on header files of a specific library is not exactly portable, in this case even less so if you write in C, not C++. This is clearly not an answer to the question. Correct answers are further down. They have only one or two upvotes or even less. – Ganny

what about using constexpr and shift operators for this purpose? – Gearard

This is implementation-defined in C and undefined in C++ right? – Norrie

I love how so many compile-time solutions relying on the boost header trick broke with the 1.73 release because it was obviously an implementation detail header. – Leuctra

Is sizeof(char) == sizeof(short int) even possible? – Slinky

@user16217248 according to the C standard, it is a situation that’s allowed in implementations, but not one I’ve seen in any actual implantation. The only guarantee is that char is the smallest unit in the implementation, and that a short int is at least as large as char and could hold the range [-32768, 32767]. – Biffin

@Biffin This would also require that CHAR_BIT > 8 – Slinky

There really exist DSP processors where CHAR_BIT == 16. Some of them are pretty widely used. – Sacramental

Answer 2

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++ macros
Clang/LLVM                 clang -dM -E -x c /dev/null      clang++ -dM -E -x c++ /dev/null
GNU GCC/G++                gcc   -dM -E -x c /dev/null      g++     -dM -E -x c++ /dev/null
Hewlett-Packard C/aC++     cc    -dM -E -x c /dev/null      aCC     -dM -E -x c++ /dev/null
IBM XL C/C++               xlc   -qshowmacros -E /dev/null  xlc++   -qshowmacros -E /dev/null
Intel ICC/ICPC             icc   -dM -E -x c /dev/null      icpc    -dM -E -x c++ /dev/null
Microsoft Visual Studio (none)                              (none)
Oracle Solaris Studio      cc    -xdumpmacros -E /dev/null  CC      -xdumpmacros -E /dev/null
Portland 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.

Chenab

I'm not familiar with Microsoft's compilers, but ARM could potentially run in either endian mode. I'm not sure if it is possible to check at compile time for it. – Extort

So, do you feel the snippet you provided is general enough? For all the compilers you listed at least? – Carricarriage

@Extort It should be, since the compiler will definitely know which endianness it is compiling for. – Gossipmonger

+1 This is a "messy" solution but one that works on common platforms and at least compiles everywhere else. – Nocturne

C'mon, instead of one liner solution you suggest to list zillions of existing predefined macroses which may outdate at any moment. – Destructor

Byte order macro in arm-none-eabi and x86_64-w64-mingw32 is defined as #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ – Shelia

Answer 3

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.

Spandau

No, it isn't, not even when you give it a const for the type. – Ministerial

@einpoklum: A union's size is the the largest type, in this case, unsigned int (usually 4 bytes), so the initialization is essentially 'unsigned int x = 1;'. Using the 'c' field pulls off the first sizeof(unsigned char) bytes, or, essentially 'x & 0xff000000'. (At least, I assume that's how it works, I couldn't find documentation saying that.) So if big-endian, 'x' will be 00 00 00 01 and (x & 0xff000000) == 0 == false. If little-endian, 'x' will be 01 00 00 00, so (x & 0xff000000) == 1 == true. – Brummell

@prewett: I actually meant "can you make the explanation part of the answer?" ... I actually do understand why this works myself, but the syntax might be a bit cryptic for some. – Carricarriage

using boost in C++: #include <boost/endian/conversion.hpp> static_assert( boost::endian::order::native == boost::endian::order::little, "you got some computer there!" ); – Brinker

This does not work in Visual Studio, says it's not a constant expression – Utile

@Utile report a bug. If you try simplifying the expression by removing the define and breaking to multiple lines (it would be easier though if you compile along the way by something working, for example gcc), you'll see that all it does in a nutshell is creating an object of the union, then accessing its member. That's definitely okay. – Foucault

That's not a constant expression because it violates the rule that "Cast operators in an integer constant expression shall only convert arithmetic types to integer types, except as part of an operand to the sizeof operator." The cast here casts to an union type. See 6.6.1 of the C99 standard, open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf "An implementation may accept other forms of constant expressions." but I'm not aware of an implementation that accepts the above. – Janie

@real-or-random: There is no cast operator whatsoever in this expression. The only operator present is the . (member access) operator. However, it violates the rules on operands; compound literals are not one of the operand types allowed in arithmetic constant expressions. – Spandau

@R..GitHubSTOPHELPINGICE Oh indeed, you're right, I wasn't really aware of compound literals. – Janie

Answer 4

Interesting read from the C FAQ:

You probably can't. The usual techniques for detecting endianness involve pointers or arrays of char, or maybe unions, but preprocessor arithmetic uses only long integers, and there is no concept of addressing. Another tempting possibility is something like

  #if 'ABCD' == 0x41424344

but this isn't reliable, either.

Subrogation

Why is this not reliable? A multi-character constant is indeed the only valid way of doing it (in C++, C99 allows the union thing). The result is of course implementation defined, but that's what it has to be since the order of bytes (which is just what you're trying to figure out!) is implementation-defined. Every other method is either undefined behavior (unions, type-punned pointers, etc), or total shit (using Boost, which is nothing but platform detection via #ifdef followed by a hand-coded #define). – Hideaway

One might be tempted to try with wide character literals in C++14 instead (I actually did try, since GCC annoyingly warns about multi-character literals) but it turns out that the standard is pretty prohibitive in what you can cast them to, and anything I tried fails with an error. Something like if( (char[4])(U'A')[0] == 65) would do, if the cast was legal. But the multi-character constant is indeed completely legal as-is. – Hideaway

@Damon: In case of cross-compilation, endianness of the target machine may be different than endianness of the compilation machine. Preprocessor would pick the latter one, I suppose. – Parallelogram

Answer 5

I would like to extend the answers for providing a constexpr function for C++

union Mix {
    int sdat;
    char cdat[4];
};
static constexpr Mix mix { 0x1 };
constexpr bool isLittleEndian() {
    return mix.cdat[0] == 1;
}

Since mix is constexpr too it is compile time and can be used in constexpr bool isLittleEndian(). Should be safe to use.

Update

As @Cheersandhth pointed out below, these seems to be problematic.

The reason is, that it is not C++11-Standard conform, where type punning is forbidden. There can always only one union member be active at a time. With a standard conforming compiler you will get an error.

So, don't use it in C++. It seems, you can do it in C though. I leave my answer in for educational purposes :-) and because the question is about C...

Update 2

This assumes that int has the size of 4 chars, which is not always given as @PetrVepřek correctly pointed out below. To make your code truly portable you have to be more clever here. This should suffice for many cases though. Note that sizeof(char) is always 1, by definition. The code above assumes sizeof(int)==4.

Lanni

Aren't all these type-punning techniques implementation defined behaviour (or even undefined behaviour)? I currently don't know of implementations where reading a union meber different from the one written last really fails, but I guess strictly speaking it is non portable. – Oberheim

@Oberheim That is because using code that depends on the endianness of the machine is implementation defined (or undefined -- I can't remember which) behaviour. Therefore any code that detects endianness also uses implementation defined behaviour. I don't think that integers are required to be big or little endian, that is I think that a compiler is allowed to use something like PDP endian as long as the arithmetic operations are correct. If you want your code to be completely portable you would have to use an endian-independent method (e.g. (data[0] << 8) | data[1]). – Conspecific

@Conspecific Yes, endian sensitive code is implementation dependent, but the implications what should happen on each architecture is more or less clear. For reading a different member of a uninion other than the one that was written last it is not that clear. As I wrote before, this is currently more or less a standards discussion, in practice it should work anyway. – Oberheim

@Oberheim Yes, in practice this should work. I just wanted to make it clear that there isn't a way to check endianness without using implementation defined behaviour, as your comment might be interpreted as implying that there is a way (that doesn't use type punning) to check what the machine's endianness is without invoking implementation defined behaviour. – Conspecific

–1 Fails to compile with clang (it's clever and a few weeks ago I thought it would work, then tested with clang and learned). – Erin

@Cheersandhth.-Alf Indeed. Since Clang 3.2 you get the error "read of member 'cdat' of union with active member 'sdat' is not allowed in a constant expression". I wasn't aware of "active members" of unions. I wonder if it is in the Standard? See here, goo.gl/Gs6qrG. Oh yes, https://mcmap.net/q/15754/-accessing-inactive-union-member-and-undefined-behavior explains, that C++11 disallows what C11 allows. Thanks. I'll update my answer. – Lanni

IIRC, type punning through char arrays is explicitly allowed. – Podesta

@AlexandreC. Also in C++ (...11), or do you mean C? Even if, using a char-array as-part-of a union is probably not included in "type punning through char[] is allowed", it could still be forbidden via a union -- in contrast to accessing it through casted a pointer of the wring type. – Lanni

You can type pun by copying to a char array and back, but not through a union. – Podesta

@Cheers, towi, can you check on a little modified solution in form of question: Finding endian-ness programatically at compile-time using C++11. If it's not problematic, then probably I can post it as a solution in one of the endian-ness related questions. – Allophone

This assumes that size of int is four times the size of char. This is wrong. Int and char can, for example, have the same size (such as 32 bits). – Nocturne

Answer 6

Use CMake TestBigEndian as

INCLUDE(TestBigEndian)
TEST_BIG_ENDIAN(ENDIAN)
IF (ENDIAN)
    # big endian
ELSE (ENDIAN)
    # little endian
ENDIF (ENDIAN)

Fungus

Worth noting, that module has been superseded as of CMake 3.20 by the CMAKE_<LANG>_BYTE_ORDER variable. – Thyroxine

Answer 7

Not during compile time, but perhaps during runtime. Here's a C function I wrote to determine endianness:

/*  Returns 1 if LITTLE-ENDIAN or 0 if BIG-ENDIAN  */
#include <inttypes.h>
int endianness()
{
  union { uint8_t c[4]; uint32_t i; } data;
  data.i = 0x12345678;
  return (data.c[0] == 0x78);
}

Comportment

Birryree's answer and mine overlapped, but each of our examples appears to do pretty much the same thing. – Comportment

Invokes UB, you can only read from the last union member that was written to. – Weisler

@GMan: I agree it's ambiguous, but that seems to conflict with other parts of the standard that explicitly allow you to access an object's representation as an overlaid char array. – Spandau

@R: Good point. Had it been a char that would have been fine, but uint8_t isn't (necessarily) a char. (Does that mean the behavior in this case is strictly implementation-defined, instead of undefined?) – Weisler

Answer 8

From Finally, one-line endianness detection in the C preprocessor:

#include <stdint.h>

#define IS_BIG_ENDIAN (*(uint16_t *)"\0\xff" < 0x100)

Any decent optimizer will resolve this at compile-time. gcc does at -O1.

Of course stdint.h is C99. For ANSI/C89 portability see Doug Gwyn's Instant C9x library.

Pugilism

This won't work on a platform that does not have uint16_t (such as SHARC) and only has uint_least16_t (which is 32 bits wide). – Nocturne

Of course, it is also illegal in C++ – Faletti

Answer 9

I took it from rapidjson library:

#define BYTEORDER_LITTLE_ENDIAN 0 // Little endian machine.
#define BYTEORDER_BIG_ENDIAN 1 // Big endian machine.

//#define BYTEORDER_ENDIAN BYTEORDER_LITTLE_ENDIAN

#ifndef BYTEORDER_ENDIAN
    // Detect with GCC 4.6's macro.
#   if defined(__BYTE_ORDER__)
#       if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)
#           define BYTEORDER_ENDIAN BYTEORDER_LITTLE_ENDIAN
#       elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__)
#           define BYTEORDER_ENDIAN BYTEORDER_BIG_ENDIAN
#       else
#           error "Unknown machine byteorder endianness detected. User needs to define BYTEORDER_ENDIAN."
#       endif
    // Detect with GLIBC's endian.h.
#   elif defined(__GLIBC__)
#       include <endian.h>
#       if (__BYTE_ORDER == __LITTLE_ENDIAN)
#           define BYTEORDER_ENDIAN BYTEORDER_LITTLE_ENDIAN
#       elif (__BYTE_ORDER == __BIG_ENDIAN)
#           define BYTEORDER_ENDIAN BYTEORDER_BIG_ENDIAN
#       else
#           error "Unknown machine byteorder endianness detected. User needs to define BYTEORDER_ENDIAN."
#       endif
    // Detect with _LITTLE_ENDIAN and _BIG_ENDIAN macro.
#   elif defined(_LITTLE_ENDIAN) && !defined(_BIG_ENDIAN)
#       define BYTEORDER_ENDIAN BYTEORDER_LITTLE_ENDIAN
#   elif defined(_BIG_ENDIAN) && !defined(_LITTLE_ENDIAN)
#       define BYTEORDER_ENDIAN BYTEORDER_BIG_ENDIAN
    // Detect with architecture macros.
#   elif defined(__sparc) || defined(__sparc__) || defined(_POWER) || defined(__powerpc__) || defined(__ppc__) || defined(__hpux) || defined(__hppa) || defined(_MIPSEB) || defined(_POWER) || defined(__s390__)
#       define BYTEORDER_ENDIAN BYTEORDER_BIG_ENDIAN
#   elif defined(__i386__) || defined(__alpha__) || defined(__ia64) || defined(__ia64__) || defined(_M_IX86) || defined(_M_IA64) || defined(_M_ALPHA) || defined(__amd64) || defined(__amd64__) || defined(_M_AMD64) || defined(__x86_64) || defined(__x86_64__) || defined(_M_X64) || defined(__bfin__)
#       define BYTEORDER_ENDIAN BYTEORDER_LITTLE_ENDIAN
#   elif defined(_MSC_VER) && (defined(_M_ARM) || defined(_M_ARM64))
#       define BYTEORDER_ENDIAN BYTEORDER_LITTLE_ENDIAN
#   else
#       error "Unknown machine byteorder endianness detected. User needs to define BYTEORDER_ENDIAN."
#   endif
#endif

Damali

This was perfect! Here is where the code came from. It is MIT licensed – Elaterin

Answer 10

I once used a construct like this one:

uint16_t  HI_BYTE  = 0,
          LO_BYTE  = 1;
uint16_t  s = 1;

if(*(uint8_t *) &s == 1) {   
   HI_BYTE = 1;
   LO_BYTE = 0;
} 

pByte[HI_BYTE] = 0x10;
pByte[LO_BYTE] = 0x20;

gcc with -O2 was able to make it completely compile time. That means, the HI_BYTE and LO_BYTE variables were replaced entirely and even the pByte acces was replaced in the assembler by the equivalent of *(unit16_t *pByte) = 0x1020;.

It's as compile time as it gets.

Roxane

Answer 11

To my knowledge no, not during compile time.

At run-time, you can do trivial checks such as setting a multi-byte value to a known bit string and inspect what bytes that results in. For instance using a union,

typedef union {
    uint32_t word;
    uint8_t bytes[4];
} byte_check;

or casting,

uint32_t word;
uint8_t * bytes = &word;

Please note that for completely portable endianness checks, you need to take into account both big-endian, little-endian and mixed-endian systems.

Kuehn

hmm, it's not too difficult to do in runtime I guess... using some pointer casting, like so: char p[] = {0, 1}; short* ptr = (short*)p; if(*ptr == 1){ we're big endian}, am I right? – Depress

Does the number of mixed-endian systems for which C11 or later has been ported exceed the number of systems were the least significant bit of an integer is stored in the most significant bit of a byte? Either would be theoretically allowed by the Standard, but I don't think either should be considered relevant by programmers. – Marrilee

Answer 12

For my part, I decided to use an intermediate approach: try the macros, and if they don't exist, or if we can't find them, then do it in runtime. Here is one that works on the GNU-compiler:

#define II      0x4949     // arbitrary values != 1; examples are
#define MM      0x4D4D     // taken from the TIFF standard

int
#if defined __BYTE_ORDER__ && __BYTE_ORDER__ == __LITTLE_ENDIAN
     const host_endian = II;
# elif defined __BYTE_ORDER__ && __BYTE_ORDER__ == __BIG__ENDIAN
     const host_endian = MM;
#else
#define _no_BYTE_ORDER
     host_endian = 1;            // plain "int", not "int const" !
#endif

and then, in the actual code:

int main(int argc, char **argv) {
#ifdef _no_BYTE_ORDER
    host_endian = * (char *) &host_endian ? II : MM;
#undef _no_BYTE_ORDER
#endif

// .... your code here, for instance:
printf("Endedness: %s\n", host_endian == II ? "little-endian"
                                            : "big-endian");

return 0;
}

On the other hand, as the original poster noted, the overhead of a runtime check is so little (two lines of code, and micro-seconds of time) that it's hardly worth the bother to try and do it in the preprocessor.

Fink