My hardest bug ever was the following: A weapon's camera tracked the simulated target perfectly, but there were occasional hiccups, where the camera jumped ran

My hardest bug ever was the following: A weapon's camera tracked the simulated target perfectly, but there were occasional hiccups, where the camera jumped randomly. The camera rotation data were confirmed, through Wireshark, to be valid, except for very specific values. It turned out to be the following problem: a function that converted the endianess of float32 values returned the endianess-switched value as a result, rather than change the destination buffer directly. Somewhere in the process, the x86 hardware expanded the switched float value to 80 bits, stored it in the internal FPU stack, and then this value was retrieved from the stack as a float32 and send over the network. In some cases, this conversion altered the value in such a way that the camera jumps were not frequent. The code that did this conversion was deep into a library that has been given to us and that it was widely used in the contractor's company for all Simulation needs. The problem got away when I replaced the PDU handling with custom code which switched endianess of floats in an appropriate manner (i.e. directly to the destination buffer). The problem most probably was created because the 'standard' functions for integer endianess swap have the form long ntohl(long v); short ntohs(short v); and the author of the library thought that following: float ntohf(float f); was going to be the same as the above.