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
Previous text:
2003-02-26 11:14: Subject: Floating point (conversion) bug (affected: v7.4 & v7.5; may be Hilfe only)
Quite possibly. I wonder why it doesn't like it. I still consider that a bug, though, since 1e1000 work.
/ Mirar