As was explained in the stackoverflow thread, reverse is used to deal with endianness issues. i.e. a file written in big-endian order is being read on a little-endian machine or visa versa.
That issue is very different from writing 32 bit integers to a file from a 32 bit application and expecting to read them back correctly in a 64 bit application on the same machine where the endianness is the same. i.e. reverse is not needed unless the file was written in a different endian order.
Bottom line is that you need to know the format of the file so that you know in advance the type of data you're trying to read. From the GdsHeader you have posted, it appears that this type information is encoded in the header.
Assuming that the type indicator correctly tells you that you are trying to read some number of 32 bit integers, then you want to be reading into an explicit 32 bit data type such as int32_t (may or may not be defined as such in your implementation). If you have endianness issues to deal with, then you will want to call reverse on the int32_t data item. You should now have a 32 bit integer in the correct format. Finally, assign that 32 bit integer to a 64 bit integer for your 64 bit application to deal with.
Thanks a lot for your better explanation. I really need this kind of information. Could you please provide input on the union. As in the the code,They allocate memory only for one_ascii and always write one_ascii.
In 32bit the size of pointer is 4 byte and 64bit size of pointer 8 byte. Does it also consideration issue when we deals in 64bit.
The size of the pointer does not matter in this situation. It's not the pointer that is being written to disk, it is what the pointer points to that is being written to disk.
I'm assuming you're trying to maintain the same file format on disk. If you are, then you have an inherrent problem when moving to a 64 bit platform. How are you going to represent a 64 bit int (in memory) in a 32 bit int (on disk) without possibly losing data?
The union is not directly allocating any memory for the data items. It is being used to allow each of the various data types to be addressed through a character pointer (*one_ascii). If you look carefully at the legacy code, you should see that it is writing *one_ascii for some number of bytes depending on the data type of the item (short=2, int=4, etc) that was appropriate on a 32 bit platform.
Writing binary data in character address order is non-portable due to endianness issues.
fwrite writes whatever you tell it to. It does so in character address order regardless of endianness.
What I said was "Writing binary data in character address order is non-portable" since the order of the bytes is different between a big-endian and a little-endian platform.
Lets take the case of a 16 bit short.
On a big-endian machine, the bytes are
0: MSB 1: LSB
On a little-endian machine, the byte are:
0: LSB 1: MSB
So you need to know the order the bytes were written and and the order that you want the bytes. If not the same, then you need to call reverse.
You also need to make sure you are using compatible data types. As has been pointed out several times, sizeof(int) is different on 32 bit and 64 bit machines.
You can't simply read a 32 bit int (4 bytes) into a 64 bit int (8 bytes) using character I/O without taking special care as to alignment, byte order and padding.