C Memory layout question

Soldato
Joined
7 Apr 2004
Posts
4,212
Hi,

With variables like an 8 byte double or 4 byte int, is the memory layout exactly the same across Windows, Linux and OSX assuming the endianness is the same?

Say for example, I copy 8 bytes from a double on Linux into a double on Windows, will it work or explode?

Thanks,

Jack
 
As far as a uint32 goes, what else could impact it apart from endianness? Each bit is just a flag for 2^n and there's no metadata to worry about.

Presumably all of the environments expect floating point encoding to use the same standard (IEEE 754..?) but I don't know much about that!
 
Last edited:
Not all types are the same length on all platforms if that is what you are asking... i.e. a long or a double may be a different length depending on the compiler. (Not entirely sure how often they are different in practice though, I'm sure I've seen a table somewhere)
 
Not all types are the same length on all platforms if that is what you are asking... i.e. a long or a double may be a different length depending on the compiler. (Not entirely sure how often they are different in practice though, I'm sure I've seen a table somewhere)

As said it does depend on the type of compiler as far as i am aware, and i have seen a table but cannot remember where, maybe a google search may help.
 
and how do you plan to do that? (not taking the mick here, but if you can explain how you would do that, i think you might answer your questions)

Ok thanks guys, let me give an example of what im doing, I need to save data in double variables (8 bytes) to disk (I know this isnt the best way but its ideal for what im doing), and i need it to work for windows, mac and linux. Is a double 8 bytes on all these OSs, and is the memory encoding IEEE standard?

example of how im doing this: (working fine on linux, havent tested on windows/mac)
Code:
double a = 4;
unsigned char *p = (unsigned char *) &a;

for(int i = 0; i < sizeof(double); i++)
{
      bytes.append(p[i]);
}

Thanks,
Jack
 
With that code you may run into trouble reading the binary file back into doubles if for instance it was compiled and saved in one compiler that used, for the sake of argument, 4 bytes for a double and then tried to load it off of a compiler that used an 8 byte double because then essentially you'd end up trying to read 8 bytes and run into your other data.

Unfortunately I don't know how real world that information is, basically look up the information sizes for your types in the GCC manual, the VC manual (or mingw, or whatever you plan to compile with for windows), and see if the types are the same size. I think to avoid the problem you'd need to use the lower type size, basically limiting the precision a bit.

Heres the list for VC:
http://msdn.microsoft.com/en-us/library/cc953fe1(VS.80).aspx

IIRC the C++ spec basically says that the next type up can't be smaller than the next type down. (You can see that for the VC compiler as the double and long double are the same size).
 
What you would do in this case is to encode everything into split bytes, so an 8 byte double would suddenly become 8 unsigned char's.

Each version of your software would have the appropriate re-construction routines for that platform/compiler.

Doing this is useful as it also solves the floating point/network problem (there are issues sending floating point numbers across a network so you just encode them into lots of single bytes)
 
Back
Top Bottom