I learned something today.

Ok. So in gcc 2.95.3, you can't reinterpret_cast a uint32 into a float - because that could cause bad stuff. You can, however, trick the compiler by reinterpret_cast-ing the address of a uint32 to a float pointer and dereference it to get a similar result (and vice versa). This all seems to work fine and dandy until you get up to numbers between 4,286,578,688 and 4,290,772,991. That range of numbers, when reinterpret_cast-ing into a float has an invalid exponent, which means it is a 1.#NAN. Now, if you try and copy that float into another float, YOU AREN'T guaranteed that the two floats are bitwise equivalent! Turns out that 2^22 is added to the uint32 version of the number in the conversion! (4,194,304), which is the first digit of the mantissa. So, when you get someone who tries to pass a uint32 around by reinterpreting the data into a float, transmitting it over a network and reinterpret it back to a uint32, you get all kinds of problems when you get into the high ranges. When counting ticks, getting into those ranges is almost guaranteed.

Talk about a difficult bug to track down.

*The more you know*