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
