accept numbers with large exponent

[grisumbras]

This changes treatment of numbers with exponents larger than INT_MAX. The current behaviour is somewhat arbitrary: we reject numbers with exponents that do not fit into INT_MAX, but we accept numbers with exponents that do not fit in double (we parse those numbers as infinity).

This PR removes the inconsistency by just setting exponent to INT_MAX. The alternative solution to inconsistency -- making it an error if the exponent doesn't fit into double is undesirable. Parsing such numbers as infinity/zero is actually standard practice.

[codecov]

Codecov Report

Merging #892 (3d751ad) into develop (6a034f2) will decrease coverage by 0.02%.
The diff coverage is 88.23%.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #892      +/-   ##
===========================================
- Coverage    92.99%   92.97%   -0.02%     
===========================================
  Files           85       85              
  Lines         8061     8072      +11     
===========================================
+ Hits          7496     7505       +9     
- Misses         565      567       +2     

Impacted Files	Coverage Δ
include/boost/json/basic_parser_impl.hpp	98.44% <88.23%> (-0.15%)	⬇️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6a034f2...3d751ad. Read the comment docs.

[pdimov]

This will theoretically fail for numbers like 0.000....0001e2147483648 where the number of zeroes is close to 2147483647, but I suppose this can never happen in practice.

Does TEST_GOOD check that the parsed value is zero or infinity in these cases?

[cppalliance-bot]

Benchmark test results. More info at https://benchmark.cppalliance.org/jsonbenchmarks-pullrequests/892/pullrequest.html

[grisumbras]

Does TEST_GOOD check that the parsed value is zero or infinity in these cases?

No, it only tests that parse doesn't result in an error.

[grisumbras]

This will theoretically fail for numbers like 0.000....0001e2147483648 where the number of zeroes is close to 2147483647, but I suppose this can never happen in practice.

Maybe we should consider such numbers errors instead (as far as I can see, we don't even check for overflow of the corresponding variable at the moment).

[pdimov]

Considering them errors should be fine.

[cppalliance-bot]

Benchmark test results. More info at https://benchmark.cppalliance.org/jsonbenchmarks-pullrequests/892/pullrequest.html

[cppalliance-bot]

Benchmark test results. More info at https://benchmark.cppalliance.org/jsonbenchmarks-pullrequests/892/pullrequest.html

[cppalliance-bot]

Benchmark test results. More info at https://benchmark.cppalliance.org/jsonbenchmarks-pullrequests/892/pullrequest.html

[cppalliance-bot]

Benchmark test results. More info at https://benchmark.cppalliance.org/jsonbenchmarks-pullrequests/892/pullrequest.html