Solaris

Hi,
I am getting expected values with the way I wrote in my previous two posts. I think the source code (not available, as of now) which has written this binary file has been written like that. Else how is it possible to get the expected the values ?

---------- Post updated at 06:41 PM ---------- Previous update was at 06:38 PM ----------

Any thoughts on this behavior ?

What is the exact data type at those locations? What is the source code you're using to read it? The more specific data you can present, the better.

Cross-platform coding is tedious. Literally every bit has to be accounted for. Which is why in cases where space and performance aren't too much of an issue I like to use portable formats like XML or even simple ASCII text.

True.
I am inferring the exact datatypes at those locations by looking at the parser code bcos original BIN file generation source is not there. And, yes, this is very tedious ! That is why, as you said we have XMLs. But, we always have some legacy systems with which sometimes we have to adjust.

It doesn't make sense for a binary file to contain both big and little endian values but this happens and sometimes there are even explanations about it.
However, if your Windows little endian code reads correctly say a 16bit or 32 bit integer value AND the very same code compiled on a big endian machine read the very same values at the same location without byte swapping, then you are just lucky enough to have a value that reads the same in both standards, like (assuming 16 bit unsigned integers) 0, 257, 514, 771, ..., 65535.

What about 32-bit unsigned long ?
In the parser code it is tryng to read something like this -

unsigned long temp = *(unsigned long *) ptr;It gives a value like this "2030043136" which is not expected. Now I tried to swap 32-bits
like this -

unsigned long temp = Swap32Bits(*(unsigned long *) ptr);
but still not sure of the correct value ! How to test such cross-platform code ?

Not sure about how Swap32Bits is implemented but your value converts to 121 which looks a pretty valid number.

Yes. That is the value I am getting using this operation :

(((data) >> 24) & 0x000000FF) | (((data) >> 8) & 0x0000FF00) | (((data) << 8) & 0x00FF0000) | (((data) << 24) & 0xFF000000) ;