[Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)

[Tim Peters]

[atof and strtod act differently given denormals on both Windows &
 Solaris]

[Guido]
> ...
> Apparently strtod() and atof() differ in implementation, even though
> the Solaris man page says "The atof(str) function call is equivalent
> to strtod(str, (char **)NULL)."

Ya, their man page is lying.  atof() existed in the mists of prehistory and
typically did no error checking at all.  IIRC, ANSI C introduced strtod(),
which generally got implemented as a layer of error-checking around atof.

I have to take it back that this is a bug in MS's strtod:  DBL_MIN is MS's
limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero
inputs with absolute value smaller than that.

> We could fix this by changing float() to do its own syntax checking
> and then use atof()...  Is it worth it?

Depends on your goal <wink>:  do you want more extreme cases, like 1e-500,
to blow up (strtod) or underflow to 0 (atof)?  The example in the original
test case is subtler because atof made it *appear* to be "a regular old
number"; in fact, it's not, it's small enough that it falls into 754's
"denormalized" range.  This means the conversion loses some extraordinary
amount of-- but not all --information (whereas 1e-500 is below even the
denorm range:  conversion loses all information).

Without a coherent strategy for dealing with 754 issues, it's hard to decide
which is better.  Since strtod() is more restrictive, if this is worth
bothering about at all now (for P3K I think 754 needs to be taken
seriously), I actually recommend changing  current atof() calls to use
native strtod() instead.