Little Endian to Big Endian

I don't care where you test for endianness -- whether you have two completely separate file-loading functions, or whether you have two different implementations of a readInt32 function, or whether you have a big ugly mess with a bunch of

akb825 Wrote:64 bit computers are the same as 32 bit as far as endianness is concerned.

This is directed towards the original author, but keep in mind that on 64-bit computers, sizeof(float/int/bool/etc.) are 8 bytes instead of 4 (64 bits = 8 bytes). This means that when you want to read in a float or an int or something, make sure you just type a 4 instead of using sizeof or it might be unreliable.

imikedaman Wrote:This is directed towards the original author, but keep in mind that on 64-bit computers, sizeof(float/int/bool/etc.) are 8 bytes instead of 4 (64 bits = 8 bytes). This means that when you want to read in a float or an int or something, make sure you just type a 4 instead of using sizeof or it might be unreliable.

fread(&num, 4, 1, file) <--- something like that I think

You are mistaken. The only difference (at least on the Mac) is that longs are 64 bits instead of 32. bool, int, and float are all still 32 bit. (and double is still 64 bit, and long double is still undefined, but I believe it is 128 bits on my G5)

Note that sizeof(long double) on Mac OS X depends both on architecture and on compiler version. I think that sizeof(long double) == 8 (GCC 3.x/PPC), 16 (GCC 4.x/PPC) and 16 (GCC 4.x/x86), but on x86 the math is done on the x87 unit, which means it's done at only 80 bits of precision, and with a few other caveats. I can't verify those numbers now though (not on a Mac).

If you *ever* care about the size of an integer type, you should use the types in <stdint.h>:
int32_t is a 32-bit integer
uint64_t is an unsigned 64-bit integer
etc.

When I'm reading or writing a big-endian value, I call swapInt32Big. When I'm reading or writing a little-endian value, I call swapInt32Little. When/if I need other types than int32, I can easily add similar macros to support them.

When I'm reading or writing a big-endian value, I call swapInt32Big. When I'm reading or writing a little-endian value, I call swapInt32Little. When/if I need other types than int32, I can easily add similar macros to support them.

Thats what I meant when I said to OneSadCookie, "declare the same function, but in one if it's with a conversion, and the other it isn't". Admittedly, It was not very clear. I guess I can understand the lost CPU cycles (I hate coding something while knowing all along it's performance is less than it could be.).

Sure, that'll work. The only thing is that it clutters your file I/O code a bit. If you use a macro or a function which behaves differently depending on the endianness (as in my example), you only have to have the preprocessor checks in that one place.