integer representation problem

I have a problem with the way integers are saved to memory. I want to read in binary from a file that contains some ints and other kinds of variables. I read every byte one by one, not four by four. I use this way to try to do a kind of file copy app by myself. But then it seems that the data is reversed.

Lets say I want to store integer number 1 on a file, I hope it is in binary:

Code:

---

00000000 00000000 00000000 00000001

---

but then when I read it one byte at a time, I'd get this:

Code:

---

00000001 00000000 00000000 00000000

---

So it seem to me that things are reversed, and I found out the same while trying to do the same directly on some stacked memory... But is there any reason for this? Can it just be my compiler? Anyway, this is what is making the thing (well that's a sentence..):

Code:

---

int a = 1;
UCHAR *b;
b = (UCHAR*)&a;
std::cout        << (int)(*(UCHAR*)b)
                << (int)(*(UCHAR*)(b + 1))
                << (int)(*(UCHAR*)(b + 2))
                << (int)(*(UCHAR*)(b + 3));
//Displays 1000... Not 0001

---

you may want too see what endianess/byte order means:
http://en.wikipedia.org/wiki/Endianness

e.g. the bytes of an integerscan be stored in memory EITHER with the most significant byte first - or with the least significant byte first.

Ok then we have to deal with this... But I think it should be easier if it was Big-Endian then, as it eases our thinking to the way we normally write numbers...

I hate to point out the obvious (actually I rather like it) but the way that the numbers are stored is more about helping the coputer to operate more efficiently than about you being able to play around with the parts of a number. Normally you would be insulated from this by using a high level programming language... c++ for example. Oh, you are and you are giving up one of the most useful features! :)

Why do you actually need to do this? Perhaps there is another approach?

If you are writing a kind of file-copy application then endianess is probably irrelevant. You read the bytes in and write them out in the same order, whatever order that might be.
You should also be careful to read in and write out a decent number of bytes at a time, that is a power of two in size e.g. 32768 bytes. That way it will be much faster.

How was the file created? You could reconstruct the int like this (assumes an int is 32 bits and a byte is 8 bits):

Code:

---

  int a;
  UCHAR *b;

  //Read from file into buffer b

  a = *b | *(b+1)<<8 | *(b+2)<<16 | *(b+3)<<24;
  cout << hex << a << endl;

---

I think you're over analysing the problem.

If you want a portable solution, use a text file and do
fout << myInt; // save
fin >> myInt; // load

If you don't care so much, and just want to save the binary representation, then do
fout.write( &myInt, sizeof myInt );
fin.read( &myInt, sizeof myInt );
Yes, this may have an endian problem if you try and move the file to a different machine architecture. It may also have a size problem and an alignment problem as well.

But if it's just for the local machine and the data is private to that program, then it should work fine.