Parsing subnormal float with too many sig figs returns zero, even if it is larger than smallest subnormal

[n8xm]

I use Base.parse, I get different results than if I use Parsers.parse:

julia> parse(Float64,"9.3494547075363499E-311")
9.3494547075363e-311

julia> parse(Float64,"9.349454707536349E-311")
9.3494547075363e-311

julia> using Parsers

julia> Parsers.parse(Float64,"9.3494547075363499E-311")
0.0

julia> Parsers.parse(Float64,"9.349454707536349E-311")
9.3494547075363e-311

I believe what is happening is that:

1. We are dealing with subnormal floats
2. If the subnormal float has "too many" sig figs

It is my understanding that subnormal floats sacrifice precision in order to allow representations that are "close" to zero. However, because 9.3494547075363499E-311 is larger than the smallest subnormal float, the behavior of Base.parse is what I would expect. I would only expect a parser to return 0.0 if the number being parsed is smaller than the smallest subnormal float.

By the way, Python's built-in parser behaves like Base.parse and not Parsers.parse. Using Python 3.9.6:

>>> float("9.3494547075363499E-311")
9.3494547075363e-311
>>> float("9.349454707536349E-311")
9.3494547075363e-311

Similarly, C's atof behaves like Base.parse and not Parsers.parse:

printf("%e\n", atof("9.3494547075363499E-311"));
printf("%e\n", atof("9.349454707536349E-311"));

The above C source produces the output:

9.349455e-311
9.349455e-311

Is there a good reason why Parsers.parse behaves differently from Base.parse in this case?

[quinnj]

Sorry for the slow fix here; a PR is up that should make subnormal parsing more robust: #92