[Merge to M53] Fixup integer conversion logic.

[Merge to M53] Fixup integer conversion logic.

In bc8a64029f898286c3dcad3a6cecdc98ef30b139 we updated the FX_atonum logic
to correctly handle integer overflow. This causes issues when parsing the
Permissions flag of encrypted documents as that flag isn't encoded like other
numbers.

The Permissions flag is a unsigned value, and has to be treated as such since
the sign bit is always set. The current logic will detect an overflow of the
int value and return 0. The old logic would have detected the overflow and
returned the negative result regardless.

This CL updates the logic to do the string to int conversion as a uint32_t
and then verifies the uint32_t value, if a sign was provided, fits within
the int range, otherwise it converts it to an int and lets it be positive or
negative as needed.

Merge clean TBRing.

BUG=pdfium:539, chromium:642256
TBR=thestig@chromium.org

Review-Url: https://codereview.chromium.org/2168173002
(cherry picked from commit 6f1025492801aaa93fca2c0ed7c40a3389ad8cd1)

Committed: https://pdfium.googlesource.com/pdfium/+/b48a715c301758ff66a96f74e3921c121b317603

[dsinclair, 2016-08-30 15:20:37]

Description was changed from

==========
Fixup integer conversion logic.

In bc8a64029f898286c3dcad3a6cecdc98ef30b139 we updated the FX_atonum logic
to correctly handle integer overflow. This causes issues when parsing the
Permissions flag of encrypted documents as that flag isn't encoded like other
numbers.

The Permissions flag is a unsigned value, and has to be treated as such since
the sign bit is always set. The current logic will detect an overflow of the
int value and return 0. The old logic would have detected the overflow and
returned the negative result regardless.

This CL updates the logic to do the string to int conversion as a uint32_t
and then verifies the uint32_t value, if a sign was provided, fits within
the int range, otherwise it converts it to an int and lets it be positive or
negative as needed.

BUG=pdfium:539,chromium:642256

Review-Url: https://codereview.chromium.org/2168173002
(cherry picked from commit 6f1025492801aaa93fca2c0ed7c40a3389ad8cd1)
==========

to

==========
Fixup integer conversion logic.

In bc8a64029f898286c3dcad3a6cecdc98ef30b139 we updated the FX_atonum logic
to correctly handle integer overflow. This causes issues when parsing the
Permissions flag of encrypted documents as that flag isn't encoded like other
numbers.

The Permissions flag is a unsigned value, and has to be treated as such since
the sign bit is always set. The current logic will detect an overflow of the
int value and return 0. The old logic would have detected the overflow and
returned the negative result regardless.

This CL updates the logic to do the string to int conversion as a uint32_t
and then verifies the uint32_t value, if a sign was provided, fits within
the int range, otherwise it converts it to an int and lets it be positive or
negative as needed.

Merge clean TBRing.

BUG=pdfium:539,chromium:642256
TBR=thestig@chromium.org

Review-Url: https://codereview.chromium.org/2168173002
(cherry picked from commit 6f1025492801aaa93fca2c0ed7c40a3389ad8cd1)
==========

[dsinclair, 2016-08-30 15:20:54]

Description was changed from

==========
Fixup integer conversion logic.

In bc8a64029f898286c3dcad3a6cecdc98ef30b139 we updated the FX_atonum logic
to correctly handle integer overflow. This causes issues when parsing the
Permissions flag of encrypted documents as that flag isn't encoded like other
numbers.

The Permissions flag is a unsigned value, and has to be treated as such since
the sign bit is always set. The current logic will detect an overflow of the
int value and return 0. The old logic would have detected the overflow and
returned the negative result regardless.

This CL updates the logic to do the string to int conversion as a uint32_t
and then verifies the uint32_t value, if a sign was provided, fits within
the int range, otherwise it converts it to an int and lets it be positive or
negative as needed.

Merge clean TBRing.

BUG=pdfium:539,chromium:642256
TBR=thestig@chromium.org

Review-Url: https://codereview.chromium.org/2168173002
(cherry picked from commit 6f1025492801aaa93fca2c0ed7c40a3389ad8cd1)
==========

to

==========
[Merge to M53] Fixup integer conversion logic.

In bc8a64029f898286c3dcad3a6cecdc98ef30b139 we updated the FX_atonum logic
to correctly handle integer overflow. This causes issues when parsing the
Permissions flag of encrypted documents as that flag isn't encoded like other
numbers.

The Permissions flag is a unsigned value, and has to be treated as such since
the sign bit is always set. The current logic will detect an overflow of the
int value and return 0. The old logic would have detected the overflow and
returned the negative result regardless.

This CL updates the logic to do the string to int conversion as a uint32_t
and then verifies the uint32_t value, if a sign was provided, fits within
the int range, otherwise it converts it to an int and lets it be positive or
negative as needed.

Merge clean TBRing.

BUG=pdfium:539,chromium:642256
TBR=thestig@chromium.org

Review-Url: https://codereview.chromium.org/2168173002
(cherry picked from commit 6f1025492801aaa93fca2c0ed7c40a3389ad8cd1)
==========

[dsinclair, 2016-08-30 15:21:17]

The CQ bit was checked by dsinclair@chromium.org

[commit-bot: I haz the power, 2016-08-30 15:21:19]

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-08-30 15:21:20]

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

[commit-bot: I haz the power, 2016-08-30 15:21:20]

CLs for remote refs other than refs/heads/master must contain NOTRY=true and
NOPRESUBMIT=true in order for the CQ to process them

[dsinclair, 2016-08-30 15:21:24]

The CQ bit was unchecked by dsinclair@chromium.org

[dsinclair, 2016-08-30 15:23:03]

Description was changed from

==========
[Merge to M53] Fixup integer conversion logic.

In bc8a64029f898286c3dcad3a6cecdc98ef30b139 we updated the FX_atonum logic
to correctly handle integer overflow. This causes issues when parsing the
Permissions flag of encrypted documents as that flag isn't encoded like other
numbers.

The Permissions flag is a unsigned value, and has to be treated as such since
the sign bit is always set. The current logic will detect an overflow of the
int value and return 0. The old logic would have detected the overflow and
returned the negative result regardless.

This CL updates the logic to do the string to int conversion as a uint32_t
and then verifies the uint32_t value, if a sign was provided, fits within
the int range, otherwise it converts it to an int and lets it be positive or
negative as needed.

Merge clean TBRing.

BUG=pdfium:539,chromium:642256
TBR=thestig@chromium.org

Review-Url: https://codereview.chromium.org/2168173002
(cherry picked from commit 6f1025492801aaa93fca2c0ed7c40a3389ad8cd1)
==========

to

==========
[Merge to M53] Fixup integer conversion logic.

In bc8a64029f898286c3dcad3a6cecdc98ef30b139 we updated the FX_atonum logic
to correctly handle integer overflow. This causes issues when parsing the
Permissions flag of encrypted documents as that flag isn't encoded like other
numbers.

The Permissions flag is a unsigned value, and has to be treated as such since
the sign bit is always set. The current logic will detect an overflow of the
int value and return 0. The old logic would have detected the overflow and
returned the negative result regardless.

This CL updates the logic to do the string to int conversion as a uint32_t
and then verifies the uint32_t value, if a sign was provided, fits within
the int range, otherwise it converts it to an int and lets it be positive or
negative as needed.

Merge clean TBRing.

BUG=pdfium:539,chromium:642256
TBR=thestig@chromium.org

Review-Url: https://codereview.chromium.org/2168173002
(cherry picked from commit 6f1025492801aaa93fca2c0ed7c40a3389ad8cd1)

Committed:
https://pdfium.googlesource.com/pdfium/+/b48a715c301758ff66a96f74e3921c121b31...
==========

[dsinclair, 2016-08-30 15:23:04]

Committed patchset #1 (id:1) manually as
b48a715c301758ff66a96f74e3921c121b317603 (presubmit successful).