Ruben Safir mrbrklyn-at-panix.com=
writes:

Right but why does the for loop automatically reverse the order

WHen you loop it does this

|00|00|00|0d| =E2=86=91

|00|00|00|0d| =E2=86=91

|00|00|00|0d| =E2=86=91

|00|00|00|0d| =E2=86=91

But as a whole it reads it as

0d000000

The for loop doesn=E2=80=99t really reverse the order. That ord=
er IS THE WAY THAT INTEL STORES INTEGERS AS BYTES.

You can verify it by taking an integer and casting its address as a poin=
ter to bytes. Byte #0 will be the least significant byte. Byte #3 will be t=
he most significant byte. That=E2=80=99s what LITTLE-ENDIAN MEANS.=

ceCode cpp">#include <iostream>
#include <cstdint>
#include <cassert>
using namespace std;
int main()
{
    uint32_t number =3D 0x89AB=
CDEF;
    uint8_t* arrayOfBytes =3D (>uint8_t*) &number; // Explicit cast required=

    assert(arrayOfBytes[0] =3D=3D bn">0xEF);  // Least-significant byte is firstpan>
    assert(arrayOfBytes[1] =3D=3D bn">0xCD);  // (assuming little-endian)
    assert(arrayOfBytes[2] =3D=3D bn">0xAB);
    assert(arrayOfBytes[3] =3D=3D bn">0x89);  // Most-significant byte is lastn>
    for(int i =3D  class=3D"dv">0; i < 4; i++)
    {
        cout << hex << (int)arrayOfBy=
tes[i] << endl;
    }

    // Or here it is in reverse -- initializing an array=
 of bytes,
    // and then treating it as an integer:
    uint8_t secondArray[4n>] =3D { 0x12, 0x34, <=
span class=3D"bn">0x56, 0x78 };
    uint32_t* numberPointer =3D (t">uint32_t*) secondArray; // Cast required
    uint32_t  secondNumber =3D *numberPointer;
    assert(secondNumber =3D=3D 0x78563412);
    cout << hex << secondNumber << endl;

    return 0;
}

If you run this program on a big-endian architecture, all the assertions=
will fail. Because in big-endian, byte #0 is the most significant byte.

Adapting this to your program, the PNG file contained the bytes, in this=
order: 0x00, 0x00, 0x00, 0x0D.

But when you have those four bytes, IN THAT ORDER, and you address them =
as a single 32-bit integer on a little-endian architecture, you will see 0x=
0D000000. Because, remember, it expects to see the least significant byte f=
irst, and the most significant byte last.

CL