I found something that might be a candidate for the overflow. Around
this timeframe, some sprintf("%f") code got added to the atis handler.
The problem is, printf() can generate almost unbounded output for very
large values* and the buffer is only 10 bytes long.
* Try this: int main() { printf("%f\n", 1e300); }
The attached patch to ATC/atis.cxx runs the value through a 32 bit
integer to do the conversion, which will nicely truncate the value to
fit within a 10 byte buffer.
Note that this isn't necessarily the bug. The property in question is
a tied value, which would have to contain garbage to trigger the
overflow. Perhaps it might itself be overwritten with garbage by
another overflow, maybe by a funny terrain interaction? That would
jive with the report of a single tile causing the crash.
It's something to try, anyway.
Andy
Index: atis.cxx
===================================================================
RCS file: /var/cvs/FlightGear-0.9/source/src/ATC/atis.cxx,v
retrieving revision 1.20
diff -u -r1.20 atis.cxx
--- a/atis.cxx 24 Mar 2004 00:28:52 -0000 1.20
+++ b/atis.cxx 10 Apr 2004 15:37:57 -0000
@@ -184,9 +184,12 @@
if(ident.substr(0,2) == "EG" && fgGetBool("/sim/atc/use-millibars") == true) {
// Convert to millibars for the UK!
P *= 33.864;
- sprintf(buf, "%.0f", P);
+ sprintf(buf, "%i", (int)(P+0.5));
} else {
- sprintf(buf, "%.2f", P);
+ // Pass through an integer to avoid buffer overflows from
+ // very large values. Consider snprintf() instead...
+ int round = (int)(100*P + 0.5);
+ sprintf(buf, "%.2f", round * 0.01);
}
transmission += " / Altimeter ";
tempstr1 = buf;
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel