Fix integer-overflow in blink::IntRect::uniteEvenIfEmpty

We currently cannot guarantee the height of rect (bottom - top) <= INT32_MAX which 
causes crash in ubsan.

BUG=687488

[yigu, 2017-02-10 00:06:15]

Description was changed from

==========
Fix overflow integer


Fix overflow integer

BUG=
==========

to

==========
We currently cannot guarantee the height of rect (bottom - top) <= INT32_MAX
which 
causes crash in ubsan.

BUG=687488
==========

[yigu, 2017-02-10 14:53:23]

yigu@chromium.org changed reviewers:
+ pdr@chromium.org

[yigu, 2017-02-10 14:53:24]

yigu@chromium.org changed required reviewers:
+ pdr@chromium.org

[yigu, 2017-02-10 14:59:32]

Hi Philip, this patch is regarding a ubsan crash that caused by integer overflow
(positive# - INT32_MIN). PTAL.

cc enne@ because of the implementation of clamping integer in gfx::rect.

[pdr., 2017-02-10 18:02:47]

pdr@chromium.org changed required reviewers:
- pdr@chromium.org

[pdr., 2017-02-10 18:15:44]

Looking at the callsite, is this dangerous to return an incorrect rect in this
case? If not, I think closing the bug as WONTFIX would be okay, because overflow
is not inherently a security risk. There are many ways to get IntRect to
overflow so I think we'd want to switch the class to use saturated arithmetic
everywhere if we wanted to guarantee against this kind of bug.

[yigu, 2017-02-10 18:24:03]

On 2017/02/10 18:15:44, pdr. wrote:
> Looking at the callsite, is this dangerous to return an incorrect rect in this
> case? If not, I think closing the bug as WONTFIX would be okay, because
overflow
> is not inherently a security risk. There are many ways to get IntRect to
> overflow so I think we'd want to switch the class to use saturated arithmetic
> everywhere if we wanted to guarantee against this kind of bug.

That's true. I was surprised that this kind of issue had not been handled in the
past years. Having no security risk must be the reason that we had ignored it.
Will close this patch and mark bug WONTFIX. Thanks!