Endianness and pointer casting in C

Question

I wrote a C program on my machine with the following part of code:

uint32_t test = 0x01020304;
uint8_t array[4];

memcpy(array, &test, 4);

printf("%02x %02x %02x %02x\n",array[0], array[1], array[2], array[3]);

And it prints 04030201 but I expected 01020304.

Do I have to conclude that the machine on which I work has a little endian architecture?

@PeterA.Schneider I get a warning whithout the cast: `warning: passing argument 2 of ‘memcpy’ makes pointer from integer without a cast [-Wint-conversion]` — Raoul722, Feb 26 '16 at 11:00
Possible duplicate of [Detecting endianness programmatically in a C++ program](http://stackoverflow.com/questions/1001307/detecting-endianness-programmatically-in-a-c-program) — Cody Gray - on strike, Feb 26 '16 at 11:01
@Raoul722 - When you saw that warning, was your code `memcpy(array, test, 4);` or `memcpy(array, &test, 4);` (note the `&` on the second)? The second example is correct, and should not have given you a warning. — Andrew Henle, Feb 26 '16 at 11:55
The compiler should't warn (gcc 4.9.3 doesn't). Perhaps you inadvertently deleted the ampersand with the cast? — Peter - Reinstate Monica, Feb 26 '16 at 11:55
@PeterA.Schneider Indeed, the ampersand was deleted. Thanks for the tip! — Raoul722, Feb 26 '16 at 11:57

score 4 · Accepted Answer · answered Feb 26 '16 at 12:05

As Mohit said, yes: The output shows that the least significant bits are at lower addresses in memory, or "the little endian is first"; or "Little Endian".

This can be somewhat confusing, especially for westerners who write and read left-to-right. I can only suspect that people who read and write Hebrew or Arabic feel less puzzled.

One of the consequences is that the bit shift operators work in the opposite "direction" of what they seem to indicate.

There has been a lot of debate about the merits and disadvantages of either byte order; in the end it doesn't matter, and of course C's big achievement is to abstract from concrete architectures just enough to smooth over the differences and make programs portable (but without preventing access to the bits and bytes).

With little endian it's somewhat unintuitive that the bits in a byte are still ascending (the way we write them) right-to-left, while the bytes are ascending (if we write higher addresses left) left-to-right.

Also, the internet byte order is Big Endian so that it's important to use htonl() and friends. (Please do not re-implement these functions.)

One of the nice properties of little endian byte order is that small values are the same no matter what data type you assume at a memory location; if you write a 32 bit int with the value 23 to address x and read it later as a char it's 23; it would be 0 on a big endian machine.

Bit shift operators don't give different results depending on endianness. `a << n`, for example, is specified as giving the same value as multiplying `a` by `2`, `n` times. There are some circumstances where bit shifting gives undefined/unspecified behaviours, but that's not related to endianness. There are also middle-endian and mixed-endian machines. — Peter, Feb 26 '16 at 13:05
@Peter Exactly. That's why `<<` shifts the bytes in a little endian architecture *"right"*, if you write the memory contents down in the conventional way with lower addresses left. — Peter - Reinstate Monica, Feb 26 '16 at 13:12

score 1 · Answer 2 · answered Feb 26 '16 at 13:02

Do I have to conclude that the machine on which I work has a little endian architecture?

Yes.

Consider copying and printing the data in an endianess-independent way:

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>
#include <string.h>

int main ()
{
  uint32_t test = 0x01020304;
  uint8_t array[4];

  for(size_t i=0; i<sizeof(uint32_t); i++)
  {
    size_t shift = 8 * (sizeof(uint32_t) - 1 - i);
    array[i] = (test >> shift) & 0xFF;
    printf("%.2" PRIx8 " ", array[i]);
  }

  return 0; 
}

Endianness and pointer casting in C

2 Answers2