convert to ULONG pointer

[ryu]

Hi GURUs,

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

Consider this code:

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

The value of tmpTest is:

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

[wildfrog]

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):

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).

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:

00 00 00 01 00 01 00 01

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

- petter

[Smasher/Devourer]

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.

[gstercken]

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...

[Smasher/Devourer]

Ah! Yep, that explains it.

[ryu]

Thanks GURUs... You guys saved my day