Hi all,

Im trying to read an int from a binary file.. (As I have done many times before)

int chunkLength=0;
fileRead.read (reinterpret_cast<char*>(&chunkLength),sizeof(chunkLength));

I know (and can see) that the file contains the bytes 00 00 00 0D, so to the best of my knowledge the int should be 13 dec after the read.

BUT it contains 0D 00 00 00 or 218103808 in dec..
Why/how does this reversal happen????

Thanks for any comment on this small issue.

- Hmortensen

its because of the endianness. Read about Little endian and big endian theory.

commented: short and on the issue. +1

its because of the endianness. Read about Little endian and big endian theory.

Ok, so and int (and every other datatype) can be represented in two ways, LSB left or right.

But my additional question now is (google didn't help on this one).. Is this something I can force my compiler to handle for me? I normally use VC++ express, and have before used the same snip to read from binary files without problems, but this time I started with an empty project. So are there a definition, header og property I can set/include, to ensure that I always have LSB to the "right".

Thanks
- Hmortensen

You kinda need to know whether the binary contains LE or BE data.

Some somewhat related FAQs:
http://c-faq.com/misc/endiantest.html
http://c-faq.com/cpp/ifendian.html
http://c-faq.com/misc/byteswap.html

Or perhaps consider a text file.

As I wrote in the original questinon, I do know what I got.. Its a PNG file! Sooo, text file is not an option. ;) And I do know how to test and swap. But the question now is where/how does the compiler differentiate in the two projects??

Thanks for the links tho,
- Hmortensen

As I wrote in the original questinon, I do know what I got.. Its a PNG file! Sooo, text file is not an option. ;)

Hm. I don't see the mention -- perhaps it's my eyesight. But no matter. Clarification achieved.

And I do know how to test and swap. But the question now is where/how does the compiler differentiate in the two projects??

I don't think I'd call it a compiler issue. I would think that perhaps there oughtta be a way to test the file for its endianness and handle then integers appropraitely.

Hmm... interesting.
http://en.wikipedia.org/wiki/Portable_Network_Graphics#Technical_details

[edit]Or don't mind me, I'm just playing along at an entirely different speed, I guess. :p

8.1. Chunks

Chunks were designed to be easily tested and manipulated by computer programs, easily detected by human eyes, and reasonably self-contained. Every chunk has the same structure: a 4-byte length (in "big-endian" format, as with all integer values in PNG streams), a 4-byte chunk type, between 0 and 2,147,483,647 bytes of chunk data, and a 4-byte cyclic redundancy check value (CRC).

So I guess I'd choose ntohs , htons , ntohl , and htonl for starters.

Thanks for all your help guys,
As it turned out all my problems arose, as the first project i did was with TGA files, where the header information is in little-endian format, so ofcourse it worked. And then when working with PNG files where the header chunk is in big-endian, it didn't.

So I was focokused on the different project styles (with and without precompiled headers), and not the format of the information in the file.

Thanks again, yet anothe aspect of programming I never knew, is now known. ;)

- Hmortensen

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.