C memcpy copies bytes with little endianness

Question

I a writing a routine to append bytes to a byte_array like so

unsigned long speed = 0xfeb;
char byteArray[8];
bzero(byteArray,8); //fills every of the 8 bytes with zero
memcpy(byteArray,&speed ,4); //copies 4 bytes from speed to byteArray

After the operation i am expecting byteArray to have the value 0xfeb but it turns out that byteArray has the value 0xebf

What is happening ? is it normal for memcpy to force the result to little-endianness ? What should i do to get the result without the change of endianness ?

There's no specification. The endianess depends on your platform. — iBug, Feb 05 '18 at 09:20
The output is going to be in the system's endianness. If you want to control this, bit swap to the form you want. `__builtin_bswap32()` and others are available with all the compilers. — Tatsh, Feb 05 '18 at 09:20
`memcpy` will blindly copy data from source to destination, how data is arranged in source and destination and how it is treated is depends on your platform. — Vagish, Feb 05 '18 at 09:22
It doesn't. It copies one byte after another, in the same order. Your diagnosis is erroneous. — user207421, Feb 05 '18 at 09:23
@iBug There is a specification, and endianness is irrelevant to it. — user207421, Feb 05 '18 at 09:27
OT: bzero was deprecated. See e.g. https://stackoverflow.com/questions/17096990/why-use-bzero-over-memset — Bob__, Feb 05 '18 at 09:55
You should never use the `char` type to store raw bytes. Use `uint8_t` instead. — Lundin, Feb 05 '18 at 10:13
"but it turns out that byteArray has the value 0xebf" --> this I find incredulous. Did you mean " has the value 0xeb, 0x0f, 0x00,0x00"`? — chux - Reinstate Monica, Feb 05 '18 at 18:09

Olaf Dietsche · Answer 1 · 2018-02-05T20:01:21.490

10

memcpy just copies bytes and doesn't care about endianness:

Copies count bytes from the object pointed to by src to the object pointed to by dest. Both objects are reinterpreted as arrays of unsigned char.

If you're on a little-endian machine it will copy LSB first. On a big-endian machine it will copy MSB first, and you will get the expected 0x0f 0xeb.

Unrelated, but you shouldn't use hard-coded values, but rather sizeof, e.g.

unsigned long speed = 0xfeb;
char byteArray[sizeof(speed)];
bzero(byteArray, sizeof(byteArray));
memcpy(byteArray, &speed , sizeof(speed));

edited Feb 05 '18 at 20:01

answered Feb 05 '18 at 09:22

Olaf Dietsche

69,448
7
95
188

Code comments need update or removal. `fills every of the 8 bytes with zero` and `copies 4 bytes from speed to byteArray` are inconsistent. – chux - Reinstate Monica Feb 05 '18 at 18:13

score 2 · Answer 2 · answered Feb 05 '18 at 09:31

memcpy does exactly what it says on the tin: it copies memory. It does not mess about with the ordering of bytes.

Endianness is only relevant if you want to know how a particular bit pattern maps to the value of the integral type. Folk tend to blame endianness for all sorts of things: in the majority of occasions it has a benign effect, and that's the case here.

C memcpy copies bytes with little endianness

2 Answers2