Prevent integer overflows in ANPlusB handling

Prevent integer overflows in ANPlusB handling

BUG=628874, 628865

[meade_UTC10, 2016-07-29 07:42:13]

The CQ bit was checked by meade@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-29 07:42:28]

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

[meade_UTC10, 2016-07-29 07:44:09]

meade@chromium.org changed reviewers:
+ nainar@chromium.org

[nainar, 2016-07-29 07:51:29]

lgtm

[commit-bot: I haz the power, 2016-07-29 09:05:53]

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

[commit-bot: I haz the power, 2016-07-29 09:05:54]

Dry run: This issue passed the CQ dry run.

[meade_UTC10, 2016-08-03 03:21:14]

The CQ bit was checked by meade@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-03 03:21:28]

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

[meade_UTC10, 2016-08-03 03:21:39]

Description was changed from

==========
[Experimental] Prevent integer overflows in ANPlusB handling

BUG=628874,628865
==========

to

==========
Prevent integer overflows in ANPlusB handling

BUG=628874,628865
==========

[meade_UTC10, 2016-08-03 03:22:28]

meade@chromium.org changed reviewers:
+ esprehn@chromium.org

[meade_UTC10, 2016-08-03 03:22:28]

Hey Elliott! Is this a good way to fix these clusterfuzz bugs?

Thanks!
Eddy

[esprehn, 2016-08-03 03:56:50]

I think doing math on long values is slower, why do we want to fix these? I was
testing this recently and all browsers behave differently so there's not even an
interop issue.

That said I don't think either of these cases is actually possible to match, we
should just always return false I think? You can't get billions of nodes, you
run out of memory so doing:

3091970736n or n+3091970736

is impossible to match, I would just return false immediately for any value that
was "huge", like greater than half of MAX_INT ?

[commit-bot: I haz the power, 2016-08-03 06:29:08]

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

[commit-bot: I haz the power, 2016-08-03 06:29:09]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[esprehn, 2016-08-15 16:19:24]

https://codereview.chromium.org/2191253002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/css/CSSSelector.cpp (right):

https://codereview.chromium.org/2191253002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/css/CSSSelector.cpp:946: if (UNLIKELY(nthAValue()
== minInt || count == minInt))
how can count be minInt? count is the index of the element, I think it has to be
a positive value. I'm actually not sure why we use int instead of unsigned?

[meade_UTC10, 2016-08-16 01:29:38]

On 2016/08/15 16:19:24, esprehn wrote:
>
https://codereview.chromium.org/2191253002/diff/40001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/css/CSSSelector.cpp (right):
> 
>
https://codereview.chromium.org/2191253002/diff/40001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/css/CSSSelector.cpp:946: if
(UNLIKELY(nthAValue()
> == minInt || count == minInt))
> how can count be minInt? count is the index of the element, I think it has to
be
> a positive value. I'm actually not sure why we use int instead of unsigned?

In that case I'll see if I can change it to unsigned.