我不喜欢基于类型双关的方法——它经常会被编译器警告。这正是工会存在的意义!

bool is_big_endian(void)
{
    union {
        uint32_t i;
        char c[4];
    } bint = {0x01020304};

    return bint.c[0] == 1;
}

这个原则等同于其他人建议的类型大小写，但这更清楚——并且根据C99，它保证是正确的。与直接指针强制转换相比，GCC更喜欢这种方法。

这也比在编译时修复字节序要好得多——对于支持多架构的操作系统(例如Mac OS X上的胖二进制)，这对ppc/i386都适用，否则很容易把事情搞砸。

除非你使用的框架已经移植到PPC和英特尔处理器上，否则你将不得不进行条件编译，因为PPC和英特尔平台拥有完全不同的硬件架构、管道、总线等。这使得两者的程序集代码完全不同。

至于查找字节序，请执行以下操作:

short temp = 0x1234;
char* tempChar = (char*)&temp;

您可以让tempChar为0x12或0x34，从中可以知道字节序。

声明一个int变量:

int variable = 0xFF;

现在使用char*指针指向它的各个部分，并检查这些部分中有什么。

char* startPart = reinterpret_cast<char*>( &variable );
char* endPart = reinterpret_cast<char*>( &variable ) + sizeof( int ) - 1;

根据哪一个指向0xFF字节，现在您可以检测到字节顺序。这需要sizeof(int) > sizeof(char)，但对于所讨论的平台绝对是正确的。

除非端标头只支持gcc，否则它提供了可以使用的宏。

#include "endian.h"
...
if (__BYTE_ORDER == __LITTLE_ENDIAN) { ... }
else if (__BYTE_ORDER == __BIG_ENDIAN) { ... }
else { throw std::runtime_error("Sorry, this version does not support PDP Endian!");
...

正如Coriiander所指出的，这里的大部分(如果不是全部的话)代码将在编译时被优化掉，因此生成的二进制文件不会在运行时检查“字节顺序”。

据观察，给定的可执行文件不应该以两个不同的字节顺序运行，但我不知道是否总是这样，对我来说，在编译时检查似乎是一种hack。所以我编写了这个函数:

#include <stdint.h>

int* _BE = 0;

int is_big_endian() {
    if (_BE == 0) {
        uint16_t* teste = (uint16_t*)malloc(4);
        *teste = (*teste & 0x01FE) | 0x0100;
        uint8_t teste2 = ((uint8_t*) teste)[0];
        free(teste);
        _BE = (int*)malloc(sizeof(int));
        *_BE = (0x01 == teste2);
    }
    return *_BE;
}

MinGW无法优化这段代码，尽管它确实优化了这里的其他代码。我相信这是因为我保留了分配在较小字节内存上的“随机”值(至少有7位)，所以编译器无法知道这个随机值是什么，也不会优化函数。

我还对函数进行了编码，以便只执行一次检查，并为下一次测试存储返回值。

C编译器的工作方式(至少我知道的每个人)必须在编译时决定字节序。即使对于双端处理器(如ARM和MIPS)，您也必须在编译时选择字节顺序。

此外，对于可执行文件(如ELF)，在所有通用文件格式中都定义了字节顺序。虽然可以编写二进制的编码器代码(可能是为了ARM服务器的漏洞?)，但它可能必须在汇编中完成。