Heads up: *possible* bug in cygwin

[Charles Wilson]

Jason Tishler wrote:
> 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.

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.....).

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/