reading/writing save states

[spacy51]

I noticed that when reading or writing to a save state, the core uses sizeof() to determine the number of bytes to read.

 

This will make save states incompatible when compiled on a system where integers are not 4 bytes.

 

Code: Select all

int utilReadInt(gzFile gzFile)
{
 int i = 0;
 utilGzRead(gzFile, &i, sizeof(int));
 return i;
}

[Squall Leonhart]

hasn't been a problem so far.

[bgK]

This indeed is a problem if you want to exchange save states between 32 bits and 64 bits machines.

[Squall Leonhart]

oh?

 

well as long as the fix is able to read the current format, so as to load and save them to the new.

[SCHUMI4EVER]

This indeed is a problem if you want to exchange save states between 32 bits and 64 bits machines.

 

Wait, so all my saves made in XP will stop working when I switch to Vista Home Premium 64bit?

[bgK]

If you use a 64bits build of VBA-M and the bug is not fixed, yes.

[SCHUMI4EVER]

If I continue to use a 32bit build then everything will be fine though?

 

There has not been a 64bit build in a while so I was planning on using the 32bit build anyways.

[spacy51]

As I said, it's only a problem when int is not 4 bytes. IIRC, on Windows 64 integers are still 4 bytes, only pointers are 8 bytes long automatically.

[Tantric]

Actually you do make a good point (I think). This is something to avoid. This can be a problem for big endian vs little endian architecture. I actually don't use any of this code to avoid running into such problems =)

Here's a post I happened across just yesterday:

http://www.tehskeen.com/forums/showthread.php?p=43389

 

See shagkur's response.

[bgK]

As I said, it's only a problem when int is not 4 bytes. IIRC, on Windows 64 integers are still 4 bytes, only pointers are 8 bytes long automatically.

 

My mistake, then. However I know for sure it'll be a problem on Linux and MacOS 64bits where sizeof(int) is 8.