Ummm well, as others smarter than myself noticed, at least part of the problem is in casting a string to float:
(float)"1e308" < (float)"1e309";
(3) Result: 0
(float)"1e308" < ((float)"1e308")*10;
(4) Result: 1
(((float)"1e308")*10)/(float)"1e308";
(7) Result: 10.000000
That still leaves the segfaults to be accounted for, though.
/ rjb
Previous text:
2003-02-26 14:06: Subject: Floating point (conversion) bug (affected: v7.4 & v7.5; may be Hilfe only)
Well, what I see is (at least) two (or three?) separate issues:
- sprintf("%f",...) broken for large floats (but small enough to fit
in a double):
Pike v7.4 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
sprintf("%e", (float)"1e300");
(1) Result: "1.000e+300"
sprintf("%f", (float)"1e300");
Segmentation fault (core dumped)
..while "%g" handles this one well.
- no chance (that I could discover) of correctly printing a float that
is too big for a double, but fits in a long double (pike compiled with --with-long-double-precision):
sprintf("%e", (float)"1e308");
(13) Result: "1.000e+308"
sprintf("%e", (float)"1e309");
(14) Result: "3.403e+38"
- sprintf("%O",...) fails on big floats (but still within the range of
a double)
sprintf("%O", (float)"1e300");
Segmentation fault (core dumped)
FWIW, on my system (debian gnu/linux, x86) float.h defines DBL_MAX_10_EXP as 308, and LDBL_MAX_10_EXP as 4932.
/ rjb