convert to ULONG pointer

Hi GURUs,

I have a very simple question and I am sure GURU know the solution.

Consider this code:

Code:

---

  BYTE tmpByte[8] = {0, 0, 0, 1, 0, 1, 0, 1};
  ULONG *tmpTest = (ULONG *)(&tmpByte[0]);

---

The value of tmpTest is:

Code:

---

tmpTest[0]=16777216
tmpTest[1]=16777472

---

Does anyone know how the compiler do the calculation to result 16777216 and 16777472?

Thanks for any help in advance...

Cheers :)

Quote:

---

Does anyone know how the compiler do the calculation to result 16777216 and 16777472?

---

Whats happening is that first you fill the memory with bytes like this (hex values):

Code:

---

00 00 00 01 00 01 00 01

---

Then you make an ulong pointer, and point it at the first byte (ulongs are 4 bytes).

Code:

---

00 00 00 01 00 01 00 01

---

If you swap those bytes around you get 01 00 00 00 or 0x01000000 which is the same as 16777216.

Then you move to the next ulong:

Code:

---

00 00 00 01 00 01 00 01

---

flip the bytes and you get 0x01000100 which is the same as 16777472.

- petter

When you define tmpByte that way, here's what's stored in memory (using hex digits):

00 00 00 01 00 01 00 01 -- tmpByte[]

When you cast the pointer to a ULONG*, it still points at the same space, but dereferencing the pointer (or using array notation) addresses four bytes at a time, rather than considering them singly. So tempTest[0] refers to:

00 00 00 01 00 01 00 01 -- tmpTest[0]

What you have to know here is that the x86 architecture is little-endian, meaning that a multibyte value such as a ULONG will be stored with the least significant byte FIRST. So in order to interpret the value of tempTest[0] by hand, you need to reverse the order of the bytes:

01 00 00 00

This value is 2^24 = 16,777,216.

Next, consider tmpTest[1]. Since tmpTest is a ULONG*, each element in the array must be the size of a ULONG, which is 4 bytes (under 32-bit Windows at least), so tmpTest[1] refers to the following bytes:

00 00 00 01 00 01 00 01 -- tmpTest[1]

Once again, to account for the fact that this value is assumed to be stored in little-endian format, we must reverse the order of the bytes to compute what this value is:

01 00 01 00

This is 2^24 + 2^8 = 16,777,472.

Note that these results are not platform-independent, because some architectures are big-endian rather than little-endian, so you wouldn't perform that byte reversal step in figuring out what output you'd expect to get from the program. For more information on endianness, see cilu's excellent article here.

Edit: Argh, too slow again! Nice job, wildfrog. :)

Quote:

---

Originally Posted by Smasher/Devourer

Note that these results are not platform-independent, because some architectures are big-endian rather than little-endian, so you wouldn't perform that byte reversal step in figuring out what output you'd expect to get from the program. For more information on endianness, see cilu's excellent article here.

---

I believe that's exactly the background of ryu's question - see this thread... ;)

Ah! Yep, that explains it. :)

Thanks GURUs... You guys saved my day :)