Bug 114366 – DFG: Negative size for new Array() interpreted as large unsigned int

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Michael Saboff]

The DFG generated code treats array sizes as unsigned integers when the computation for an array can produce a negative value.

The lint interpreter and baseline JIT appear to work correctly with negative sizes, that is they both throw RangeError exceptions.

From <rdar://problem/12850273>

[Michael Saboff]

Created attachment 197353 [details]
Patch

[Filip Pizlo]

Comment on attachment 197353 [details]
Patch

r=me too

[WebKit Commit Bot]

Comment on attachment 197353 [details]
Patch

Clearing flags on attachment: 197353

Committed r148130: <http://trac.webkit.org/changeset/148130>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Darin Adler]

Is this hot enough that UNLIKELY is needed/helpful?

[Michael Saboff]

(In reply to comment #5)
> Is this hot enough that UNLIKELY is needed/helpful?

It makes sense to add UNLIKELY.  The case we care about for the bug is when the static_cast<unsigned>(size) >= 100000, but we'll also reach this patch when we can't allocated directly inline and need to get more space.  In real world, the failed allocation paths are far more likely.

I'll add the UNLIKELY and check it in.

[Michael Saboff]

(In reply to comment #6)
> (In reply to comment #5)
> > Is this hot enough that UNLIKELY is needed/helpful?
> 
> It makes sense to add UNLIKELY.  The case we care about for the bug is when the static_cast<unsigned>(size) >= 100000, but we'll also reach this patch when we can't allocated directly inline and need to get more space.  In real world, the failed allocation paths are far more likely.
> 
> I'll add the UNLIKELY and check it in.

Landed in change set r148207 <http://trac.webkit.org/changeset/148207>.