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 … Read more
#define htonll(x) ((1==htonl(1)) ? (x) : ((uint64_t)htonl((x) & 0xFFFFFFFF) << 32) | htonl((x) >> 32)) #define ntohll(x) ((1==ntohl(1)) ? (x) : ((uint64_t)ntohl((x) & 0xFFFFFFFF) << 32) | ntohl((x) >> 32)) The test (1==htonl(1)) simply determines (at runtime sadly) if the hardware architecture requires byte swapping. There aren’t any portable ways to determine at compile-time what … Read more
The current behaviour, is determined by the endianness of the underlying hardware. As almost all desktop computers are x86, this means little-endian. Most ARM OSes use little-endian mode (ARM processors are bi-endian and thus can operate in either). The reason why this is somewhat sad is the fact that it means almost nobody will test … Read more
In short, yes. Suppose we are on a 32-bit machine. If it is little endian, the x in the memory will be something like: higher memory —–> +—-+—-+—-+—-+ |0x01|0x00|0x00|0x00| +—-+—-+—-+—-+ A | &x so (char*)(&x) == 1, and *y+48 == ‘1’. (48 is the ascii code of ‘0’) If it is big endian, it will … Read more
Endianness only matters for layout of data in memory. As soon as data is loaded by the processor to be operated on, endianness is completely irrelevent. Shifts, bitwise operations, and so on perform as you would expect (data logically laid out as low-order bit to high) regardless of endianness.
That’s because %d expects an int but you’ve provided a float. Use %e/%f/%g to print the float. On why 0 is printed: The floating point number is converted to double before sending to printf. The number 1234.5 in double representation in little endian is 00 00 00 00 00 4A 93 40 A %d consumes … Read more
No, it will not be fully-portable. Packing options for structs are extensions, and are themselves not fully portable. In addition to that, C99 ยง6.7.2.1, paragraph 10 says: “The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined.” Even a single compiler might lay the bit field out … Read more
RFC1700 stated it must be so. (and defined network byte order as big-endian). The convention in the documentation of Internet Protocols is to express numbers in decimal and to picture data in “big-endian” order [COHEN]. That is, fields are described left to right, with the most significant octet on the left and the least significant … Read more
In C, C++ int n = 1; // little endian if true if(*(char *)&n == 1) {…} See also: Perl version
Use the network byte order (big endian), which is the same as Java uses anyway. See man htons for the different translators in C.