binary files make me die
Author
Hello,
I am trying to parse IFF files (lightwave models) and i am having a very simple (sounding) problem. i can read in the entire file into a char buffer. i can also read in sections of the file and parse strings from it but for some reason i cand parse out straight 4byte integers. the first four bytes of my file are 'F', 'O', 'R', 'M'. the next four is a four byte int. the int should be the length of my file - 8. (minus the 'FORM' and the size) and it is, i opened it in a gex editor, and converted from hex to base ten and the number works out. but when i read it in byte by byte, it doesn't work out, in the file the four bytes in ascii are : " '†" (two space, and symbols); in hex they
are : 00 00 27 68 (each two characters a byte). these can be read in as characters into a char[4] array and read out, but i don't know how to convert to an int (i have tried atoi but it returns 0).
thanks in advance
-Matt
[edited by - supermatt on December 15, 2003 10:39:39 PM]
Read it into either a
long
unsigned long
or a DWord.
All of these are 4 byte integer types and thats what your trying to read.
You probibly already know this but atoi will sonvert a string at an int. meaning it would be the ascii repersentation of the number.
long
unsigned long
or a DWord.
All of these are 4 byte integer types and thats what your trying to read.
You probibly already know this but atoi will sonvert a string at an int. meaning it would be the ascii repersentation of the number.
Author
i tried that, but goofey things started to happen, so i tried this:
long size = (long)charsize;
(charsize = char[4] that i read the data into)
and i get the same result actually, the result i get is 1244840 it should be 10118, the data in these files is ''endian'' encoded, might that have anything to do with it?
thanks again
-Matt
long size = (long)charsize;
(charsize = char[4] that i read the data into)
and i get the same result actually, the result i get is 1244840 it should be 10118, the data in these files is ''endian'' encoded, might that have anything to do with it?
thanks again
-Matt
char[4] buffer;// read the 4 int bytes from your IFF file into bufferint i;i = *(int*)buffer;// i holds now the integer valueEdit: If the int is stored in big-endian format just turn it around before you get the int from it.
char temp;
temp = buffer[0];
buffer[0] = buffer[3];
buffer[3] = temp;
temp = buffer[1];
buffer[1] = buffer[2];
buffer[2] = temp;
[edited by - Direct4D on December 15, 2003 12:54:50 AM]
Author
thanks, that did work, i figured out the endian thing on my own eventually, but my only remmaining question is about theory.
how does you call:
i = *(int*)buffer;
differ from:
i = (int)buffer;
i know your call is right because the other returns the wrong answer, but how do they differ? the casting as a pointer than getting what is being pointed to sounds redundant, so.... why does it work and the other not?
how does you call:
i = *(int*)buffer;
differ from:
i = (int)buffer;
i know your call is right because the other returns the wrong answer, but how do they differ? the casting as a pointer than getting what is being pointed to sounds redundant, so.... why does it work and the other not?
Casting from a pointer to an integer generally means that the integer value is whatever the memory address of the pointer is. Casting from one pointer type to another pointer type means that that memory location is reinterpreted as pointing to the new type. That is, the program then says "okay, that''s not four chars at that address, it''s an integer".
"Sneftel is correct, if rather vulgar." --Flarelocke
"Sneftel is correct, if rather vulgar." --Flarelocke
In your case, you have the char array pointer :
buffer : Hi! I'm a char array buffer ! I'm pointing to chararcters at address 0x77531212.
But, hey! there comes the casting operator!
(int) : hey, you there! Become an int!
(int)buffer : Ok! Now I'm an integer, and my value is still 0x77531212.
Look! There comes the allocation operator :
= : i, become the value of (int)buffer!
i : ok! (int)buffer, give me your value!
(int)buffer : 0x77531212.
i : great, now I'm 0x77531212.
In his case :
buffer : Hi! It's me again!
There comes the casting operator...
(int*) : you there, become a pointer to an integer.
(int*)buffer : righto! I'm now pointing to an integer at address 0x77351212!
Then, the dereference came!
* : hi there, buffer! give me the value you're pointing to!
*(int*)buffer : sure thing! /fetches integer at 0x77531212 (which happens to be "form", but as an integer).
In the end : buffer is a pointer, if you cast it to a non-pointer type, you're going wrong.
*(int*) actually CHANGES the type of the data being read. It does NOT convert the data. For instance, *(float*)&(10) will not be 10.0f, but rather some undefined float.
EDIT : ok, that was COMPLETELY ridiculous... sorry ^^
[edited by - ToohrVyk on December 16, 2003 1:13:45 PM]
buffer : Hi! I'm a char array buffer ! I'm pointing to chararcters at address 0x77531212.
But, hey! there comes the casting operator!
(int) : hey, you there! Become an int!
(int)buffer : Ok! Now I'm an integer, and my value is still 0x77531212.
Look! There comes the allocation operator :
= : i, become the value of (int)buffer!
i : ok! (int)buffer, give me your value!
(int)buffer : 0x77531212.
i : great, now I'm 0x77531212.
In his case :
buffer : Hi! It's me again!
There comes the casting operator...
(int*) : you there, become a pointer to an integer.
(int*)buffer : righto! I'm now pointing to an integer at address 0x77351212!
Then, the dereference came!
* : hi there, buffer! give me the value you're pointing to!
*(int*)buffer : sure thing! /fetches integer at 0x77531212 (which happens to be "form", but as an integer).
In the end : buffer is a pointer, if you cast it to a non-pointer type, you're going wrong.
*(int*) actually CHANGES the type of the data being read. It does NOT convert the data. For instance, *(float*)&(10) will not be 10.0f, but rather some undefined float.
EDIT : ok, that was COMPLETELY ridiculous... sorry ^^
[edited by - ToohrVyk on December 16, 2003 1:13:45 PM]
Author
thanks alot,
rediculous? yes. helpful? definately.
that explained things quite well, and i now have my exe up and parsing quite effectively
thanks again to everyone who helped with this problem
-Matt
[edited by - supermatt on December 16, 2003 2:45:34 PM]
rediculous? yes. helpful? definately.
that explained things quite well, and i now have my exe up and parsing quite effectively
thanks again to everyone who helped with this problem
-Matt
[edited by - supermatt on December 16, 2003 2:45:34 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement