i don't have the code with me at the moment, but yesterday i had a weird problem with a standard file stream, in that I would read 4 bytes into a long, record the position in the file that it's currently at, move to somewhere else based on that long, and then reset to the position where it was (so it SHOULD end back up just after the 4 bytes)...

but the problem was that for some weird reason, it incremented the position by 16 bytes, even though it read only 4 bytes

im about to leave for work in 20 minutes, and am not on my mac... but when i get back from work, i'll post the code


anyone have any ideas why it's doing this?

Reading in text mode vs binary mode can sometimes cause strange effects when you try to seek in the stream. Not sure if this really sounds like a case of that, but it's the only thing I can think of except for a flaw in your code.

I've commented out the code that seeks in the file (at the cost of not loading a string... whoopdeedoo), and just as I had remembered, the 16-byte increment is before the file.seekp(), and thusly is still a problem even without seekp() being used. Take my following code:

[code]for (i = 0; i < PEF.Loader.Header.totalImportedSymbolCount; i++){
   Location = File.tellp();
   /* wtf?! it's reading 4 bytes, but increasing location by 16?! */
   File.read((char *)&PEF.Loader.ImportedSymbols[i].ClassAndName,4);
   if (File.fail() == true){
      cout << "Failure reading PEFLoader.ImportedSymbols[" << i << "] !!" << endl;
      goto CLEANUP;
   } else {
      cout << "Loader.ImportedSymbols[" << i << "]" << endl;
      cout << " .classAndName: " << ((void *)PEF.Loader.ImportedSymbols[i].ClassAndName.classAndName) << endl;
      cout << " NameOffset : " << ((void *)(PEF.Loader.ImportedSymbols[i].ClassAndName.classAndName & kPEFImpSymNameOffsetMask)) << endl;
      cout << " Class : " << ((void *)(PEF.Loader.ImportedSymbols[i].ClassAndName.classAndName >> kPEFImpSymClassShift)) << endl;
   }
}[/code]When I breakpoint at File.read(), Location is always 0x10 more than it was on the previous breakpointed iteration.

A simple fix I could do would be to check to see if the new location isn't the expected new location compared to the old location added to the size of the object I'm reading (4 bytes), and if it's not what it's supposed to be, then add or subtract and do seekp() at that point... But I really think I shouldn't have to do that.