Strange behaviour when using pointers

Question

I have a file with some binary data as follows.

aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55         
aa 55 aa 55 36 65 fb 5f 1e 92 d8 1b 55 f7 fb 5f         
1e 92 d8 1b

I want to extract the values 55 36 65 fb 5f 1e.

If I use the following code.

temp_1 = (data_ptr[offset]);
val = temp_1 << 40;

temp_1 = (data_ptr[offset + 1]);
val |= temp_1 << 32;

temp_1 = (data_ptr[offset + 2]);
val |= temp_1 << 24;

temp_1 = (data_ptr[ts_offset + 3]);
val |= temp_1 << 16;

temp_1 = (data_ptr[ts_offset + 4]);
val |= temp_1 << 8;

temp_1 = (data_ptr[ts_offset + 5]);
val |= temp << 0;

printf("read value %"PRIx64" \n",val);

The outupt of this printf is

3665fb5f1e92

Now I also try to calculate the same value using a single 64-bit ptr cast operation.

val = *(uint64_t*)(data_ptr + ts_offset);
printf("read value %"PRIx64" \n",val);

The output of the above code is

1bd8921e5ffb6536

If you check the least significant 48-bits here 921e5ffb6536

It is the inverted compared to the first result.I am using a normal intel processor.Why is this behaviour? Is this expected.

Do you know what [Endianness](http://en.wikipedia.org/wiki/Endianness) is ? Look around on this site. there are *dozens* of questions related to it (such as [this one](http://stackoverflow.com/questions/17423967/char-pointer-returns-unexpected-value-after-being-cast-from-int). — WhozCraig, Aug 28 '13 at 22:20

score 2 · Accepted Answer · answered Aug 28 '13 at 22:31

In your code that shifts the value, you are reading the highest byte from the lowest address (bits 40-47 from offset 0). I'm guessing your second case is running on a x86 machine, thus reading the lowest byte from the lowest address (because that's how x86 is defined, as is MANY other processors, they are called "little-endian" machines).

If you want the bytes in that particular order, on a little-endian machine, you will have to get bytes one by one and shift (if you wanted a whole 64-bit value, it may have been possible to use a byteswap instruction on x86, but I doubt it's enough value in that when you then need to "undo" that by shifting and masking the 16 bits you didn't actually need).

score 1 · Answer 2 · answered Aug 28 '13 at 22:33

1

The behavior is expected.

The byte order of an integer is saved in memory varies. From least significant byte to most (Little endian) or most significant byte to least. (Big endian).

Google "endian" for tons of info or read "Guliver Travel's".

answered Aug 28 '13 at 22:33

chux - Reinstate Monica

143,097
13
135
256

Strange behaviour when using pointers

2 Answers2