People‎ > ‎John Stavrakakis‎ > ‎John's blog‎ > ‎

Endianess for 64 bit integer

posted 7 Nov 2011, 23:02 by John Stavrakakis
Want to get things ready for demonstration and there are all kinds of new problems with Windows != Mac.

Firstly, there was the well founded argument that some parameters in the protocol would benefit from being 64 bit integers. When transferring compressed data over the network, the client needs to be able to reserve enough memory for the uncompressed data. To get the ball rolling, I use a compression ratio as an indicator of how much memory to allocate. From this I had forgotten that the compression ratios I was achieving in my program were so wild 10-100x. So when describing the compression ratio as 56.7x, allocated space would be 57x. The excess unused space bothers me! So just tell the client how much to reserve exactly. Enter the long problem.

     OS           arch           size
Windows       IA-32        4 bytes
Windows       Intel 64     4 bytes
Windows       IA-64        4 bytes
Linux            IA-32        4 bytes
Linux            Intel 64     8 bytes
Linux            IA-64        8 bytes
Mac OS X      IA-32        4 bytes
Mac OS X      Intel 64     8 bytes  

One could get around this with long long, but the problem doesn't end there. Consider that the little/big endian representation of integers must be recognised. This is why there is host-to-network hton*() and network-to-host ntoh*(). But they are for short, and long only. 16 bit and 32 bit respectively. Trolling the internet for quick fixes, one could determine the sign of the integer by loading a known value into an int, then casting to a character array (so you read in memory order). 

int x = 15;
if ( *((char*)&x) == 15)
    // little endian
} else {
    // big endian
After this you could implement a byte swap. BSD has functions for byte swapping, but I haven't come across standard, cross platform method. In the end, I went back to using <stdint.h> and uint32_t. This is guaranteed goodness with htonl() ntohl() and conformance around the world with any respectable OS.

Secondly, it is taking a really long time to download the VNC screen as a Lion VNC client from a windows TightVNC server.
46 seconds later just for the first screen! and don't think thats all, the update time is just as long. Totally unusable. I am not sure if this is a Lion problem or Win7 64 bit w/ TightVNC issue.

Did I mention Xcode crashed? not once, but frequently?