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:
11234999999999999993833496141165207167137504629455791386815894971093998449766224059134612227306117948559764428592704563810063396445147361721349723249504875046156126872109285397930933011042616316938278030005998645453598490624.00
Needless to say, the static data area wasn't happy with 200+ bytes of
overflow. :)
In my copy, I fixed this with snprintf, but something nags at me that
this isn't portable to some platform we care about. We could mock up
a slow version that did an unchecked sprintf into some very large
buffer and copied the result out. Probably a better idea is to sanify
the input values so they can't have such unprintable values.
Andy
--
Andrew J. Ross NextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
