#endianess

Found this unfortunate routine in a code base:

uint32_t byteswap(uint32_t word) { uint8_t* ptr = (uint8_t*)&word; return ((ptr[3] << 24) | (ptr[2] << 16) | (ptr[1] << 8) | (ptr[0])); }

Too bad it only swaps in one direction. If you're already on a big-endian platform, this routine will do nothing! Probably not what you were expecting to happen. A correct routine will swap the byte order regardless of the platform it is running on:

I recently spent 5 hours trying to figure out why my maps I write from an own made "tiled" plugin (Java) aren't beeing read properly in my ninjarun game (C), already knowing all along it must be because of the endianess (But I'm always lazy to mess with the actual bits themselves, so I spent all my time googling for proof, before I actually start reversing byte orders).

Java stores it's stuff as big-endian whereas c will try to load it as little-endian.

There are two kinds of design architecture for memory storage: Big Endian & Little Endian. Some references are listed as blew:

Microsoft Knowledge Database

Discussion A