Use a stricter limit for the exponent range in genericParseNumber

Use a stricter limit for the exponent range in genericParseNumber

The exponent was being checked against numeric_limits<...>::max_exponent
which is the power-of-two limit. Use max_exponent10 instead. Also make
sure to apply any exponent sign prior to the range check so that
min_exponent10 can be used as the lower bound. This means computing the
base number before checking for/parsing the exponent part. This could
be slower in some cases, but reasonably only when an error is
encountered. Also, scientific notation should be fairly scarce to begin
with.

Also move declarations of local variables closer to their first use (and
in the inner-most scope possible.) Unravel the handling of/accumulation
into 'frac' when computing the decimal part.

BUG=675174
Committed: https://crrev.com/57f9189c8edf1db60a0f4e1c3c4c7dbda6d47c6e
Cr-Commit-Position: refs/heads/master@{#439522}

[fs, 2016-12-19 16:28:28]

The CQ bit was checked by fs@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-12-19 16:28:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[fs, 2016-12-19 16:29:55]

Description was changed from

==========
Use a stricter limit for the exponent range in genericParseNumber

The exponent was being checked against numeric_limits<...>::max_exponent
which is the power-of-two limit. Use max_exponent10 instead. Also make
sure to apply any exponent sign prior to the range check so that
min_exponent10 can be used as the lower bound. This means computing the
base number before checking for/parsing the exponent part. This could
be slower in some cases, but reasonably only when an error is
encountered. Also, scientific notation should be fairly scarce to begin
with.

Also move declarations of local variables closer to their first use (and
in the inner-most scope possible.)

BUG=675174
==========

to

==========
Use a stricter limit for the exponent range in genericParseNumber

The exponent was being checked against numeric_limits<...>::max_exponent
which is the power-of-two limit. Use max_exponent10 instead. Also make
sure to apply any exponent sign prior to the range check so that
min_exponent10 can be used as the lower bound. This means computing the
base number before checking for/parsing the exponent part. This could
be slower in some cases, but reasonably only when an error is
encountered. Also, scientific notation should be fairly scarce to begin
with.

Also move declarations of local variables closer to their first use (and
in the inner-most scope possible.) Unravel the handling of/accumulation
into 'frac' when computing the decimal part.

BUG=675174
==========

[fs, 2016-12-19 17:40:08]

fs@opera.com changed reviewers:
+ schenney@chromium.org

[commit-bot: I haz the power, 2016-12-19 17:54:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-19 17:54:50]

Dry run: This issue passed the CQ dry run.

[Stephen Chennney, 2016-12-19 18:21:08]

Thanks a lot for dealing with these over/underflow issues.

lgtm

[fs, 2016-12-19 19:26:33]

The CQ bit was checked by fs@opera.com

[commit-bot: I haz the power, 2016-12-19 19:27:25]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-19 19:33:52]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1482175593219890, "parent_rev":
"10f721a35827231af640c40e37320892aadfd520", "commit_rev":
"09adb4e0a4b4b2914ccabfbee5f83aecb3bf6be8"}

[commit-bot: I haz the power, 2016-12-19 19:34:25]

Description was changed from

==========
Use a stricter limit for the exponent range in genericParseNumber

The exponent was being checked against numeric_limits<...>::max_exponent
which is the power-of-two limit. Use max_exponent10 instead. Also make
sure to apply any exponent sign prior to the range check so that
min_exponent10 can be used as the lower bound. This means computing the
base number before checking for/parsing the exponent part. This could
be slower in some cases, but reasonably only when an error is
encountered. Also, scientific notation should be fairly scarce to begin
with.

Also move declarations of local variables closer to their first use (and
in the inner-most scope possible.) Unravel the handling of/accumulation
into 'frac' when computing the decimal part.

BUG=675174
==========

to

==========
Use a stricter limit for the exponent range in genericParseNumber

The exponent was being checked against numeric_limits<...>::max_exponent
which is the power-of-two limit. Use max_exponent10 instead. Also make
sure to apply any exponent sign prior to the range check so that
min_exponent10 can be used as the lower bound. This means computing the
base number before checking for/parsing the exponent part. This could
be slower in some cases, but reasonably only when an error is
encountered. Also, scientific notation should be fairly scarce to begin
with.

Also move declarations of local variables closer to their first use (and
in the inner-most scope possible.) Unravel the handling of/accumulation
into 'frac' when computing the decimal part.

BUG=675174

Review-Url: https://codereview.chromium.org/2588023002
==========

[commit-bot: I haz the power, 2016-12-19 19:34:25]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-12-19 19:37:08]

Description was changed from

==========
Use a stricter limit for the exponent range in genericParseNumber

The exponent was being checked against numeric_limits<...>::max_exponent
which is the power-of-two limit. Use max_exponent10 instead. Also make
sure to apply any exponent sign prior to the range check so that
min_exponent10 can be used as the lower bound. This means computing the
base number before checking for/parsing the exponent part. This could
be slower in some cases, but reasonably only when an error is
encountered. Also, scientific notation should be fairly scarce to begin
with.

Also move declarations of local variables closer to their first use (and
in the inner-most scope possible.) Unravel the handling of/accumulation
into 'frac' when computing the decimal part.

BUG=675174

Review-Url: https://codereview.chromium.org/2588023002
==========

to

==========
Use a stricter limit for the exponent range in genericParseNumber

The exponent was being checked against numeric_limits<...>::max_exponent
which is the power-of-two limit. Use max_exponent10 instead. Also make
sure to apply any exponent sign prior to the range check so that
min_exponent10 can be used as the lower bound. This means computing the
base number before checking for/parsing the exponent part. This could
be slower in some cases, but reasonably only when an error is
encountered. Also, scientific notation should be fairly scarce to begin
with.

Also move declarations of local variables closer to their first use (and
in the inner-most scope possible.) Unravel the handling of/accumulation
into 'frac' when computing the decimal part.

BUG=675174

Committed: https://crrev.com/57f9189c8edf1db60a0f4e1c3c4c7dbda6d47c6e
Cr-Commit-Position: refs/heads/master@{#439522}
==========

[commit-bot: I haz the power, 2016-12-19 19:37:09]

Patchset 1 (id:??) landed as
https://crrev.com/57f9189c8edf1db60a0f4e1c3c4c7dbda6d47c6e
Cr-Commit-Position: refs/heads/master@{#439522}