Andy Ross writes: > >I got bitten by some static data corruption problems while working on >the panel stuff this afternoon (which I have almost working, by the >way -- expect a big code drop tomorrow morning). I tracked it down to >a buffer overflow in auto_gui.cxx. In the string formatting code for >the labels, there are some sprintf calls that look like this: > > sprintf(buffer, "%05.2f", value); > >Where the buffer is a static variable with a length of 8. It turned >out that one of the values was a huge garbage value -- something like >1e223. > >This code looked correct to me, with the field width being less than >8. But it turns out that that C standard allows for the buffer to >overflow anyway. What happens is that the exponential form of the >number can't fit for whatever reason, so the glibc sprintf tries to >print it in (gack!) decimal. You can verify this with the following >tiny program: > > int main() { printf("%05.2f\n", 1.1235e223); } > >...which gives the following output on my machine: > >112349999999999999938334961411652071671375046294557913868158949 >710939984497662240591346122273061179485597644285927045638100633 >964451473617213497232495048750461561268721092853979309330110426 >16316938278030005998645453598490624.00 >
Note that getting a value outside of what is representable with %05.2f is probably an indication of a bug elsewhere in the program as these represent angular measurements only, where this construct is used in auto_gui.cxx This could also be related to recent changes in the auto_pilot code to run every thing through the 'properties' instead of accessing these values directly where I believe they were always clamped to a +- 360 degree range Norman _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel