VisualBoyAdvance-M

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.

 

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

hasn't been a problem so far.

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

oh?

 

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

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?

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

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.

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.

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.

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.