Jason Tishler wrote:
But that's just *wrong*. You simply move the error condition to larger strings. NDEC=42 actually makes sense -- that's (relatively close to) the most base-10 digits that a floating point number can represent (not counting those infinitely repeating base-10 numbers thanks to floating point "roundoff" -- e.g. where the closest representation to "0.1" in base-2 float is (after reconverting to base-10) 0.9999999999999.....).I concur. In fact, this problem is the root cause for the Cygwin Python SEGV that I was trying to debug in the following:http://cygwin.com/ml/cygwin-developers/2002-12/msg00027.html For those interested, Python's test_format regression test would SEGV after trying to display a 109 digit number. Unfortunately, this occurred deep in Python's garbage collection during exit which threw me off the track. Sigh... Thanks for your astute analysis. With the attached "patch," I was able to get test_format to pass. I will monitor the newlib list to see what the outcome is.
Of course, my "solution" for glib (inside pkgconfig-0.14) is even worse: "don't do that". I simply changed the format string to %42.42f instead of %10000.10000f. <g> It's not a glib problem, after all, so for now I just work around it -- and hope that an acceptable solution for the newlib issue is found. [I don't mind coding that solution, but I dunno what the "Right Thing" to do is...I'm waiting for guidance from the newlib list]
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
