Closed
Bug 310425
Opened 19 years ago
Closed 19 years ago
Array.indexOf/lastIndexOf is broken for corner cases
Categories
(Core :: JavaScript Engine, defect, P1)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla1.8beta5
People
(Reporter: igor, Assigned: brendan)
References
()
Details
(Keywords: fixed1.8, js1.6, Whiteboard: [needs SR shaver])
Attachments
(6 files, 1 obsolete file)
|
5.31 KB,
patch
|
Details | Diff | Splinter Review | |
|
18.52 KB,
patch
|
Details | Diff | Splinter Review | |
|
15.76 KB,
patch
|
mrbkap
:
review+
|
Details | Diff | Splinter Review |
|
444 bytes,
patch
|
brendan
:
review+
shaver
:
superreview+
|
Details | Diff | Splinter Review |
|
19.19 KB,
patch
|
brendan
:
review+
brendan
:
superreview+
mscott
:
approval1.8b5+
|
Details | Diff | Splinter Review |
|
1.26 KB,
patch
|
igor
:
review+
mrbkap
:
review+
shaver
:
superreview+
asa
:
approval1.8rc1+
|
Details | Diff | Splinter Review |
The current implementation of Array.indexOf/ Array.lastIndexOf has the following 2 issues: 1. [].lastIndexOf(undefined, -1) gives 0 instead of -1. This is due to lastIndexOf implementation always querying array[0] for negative indexes even if length is 0. 2. var x = []; x[1 << 30] = 1; var index = x.lastIndexOf(1); sets index to undefined, not 1 << 30, since code assumes that array index would always fit JSVAL_INT_MAX. Thus it would return INT_TO_JSVAL(1 << 30) which is JSVAL_VOID. Similar problem holds for indexOf but it would really long time to run x.indexOf() since the code would loop through 1 << 30 non-existing elements.
| Assignee | ||
Comment 1•19 years ago
|
||
Thanks for filing this -- not sure shaver is able to jump on it. I'm in Tallinn, Estonia for ACM ICFP, but may take a crack at fixing it. /be
Flags: blocking1.8b5+
Keywords: js1.6
OS: Linux → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.8beta5
| Reporter | ||
Comment 2•19 years ago
|
||
Patch consolidates indexOf/lastIndexOf implementation into single array_indexOfHelper which immediately returns -1 for array with length 0. Otherwise it runs the search loop that would properly wrap found index into JSVAL.
| Assignee | ||
Comment 3•19 years ago
|
||
Also cleans up a few minor things from the old days. Just to cut down on code size a bit more, use js_NewNumberValue in array_indexOfHelper. /be
| Assignee | ||
Comment 4•19 years ago
|
||
This should be good for 1.8b5 with a little review and testing (someone run the testsuite, my battery's low here!). /be
Attachment #197834 -
Flags: superreview?(shaver)
Attachment #197834 -
Flags: review?(mrbkap)
| Assignee | ||
Comment 5•19 years ago
|
||
Thanks again, Igor! You helping Norris get these implemented in Rhino, by any chance? ;-) /be
| Reporter | ||
Comment 6•19 years ago
|
||
(In reply to comment #5) > You helping Norris get these implemented in Rhino, by any chance? ;-) This was how I discovered the bug trying to get semantics of the extras from jsarray.c to copy it into bug 310323 and bug 310342.
| Reporter | ||
Comment 7•19 years ago
|
||
(In reply to comment #3) > Also cleans up a few minor things from the old days. Just to cut down on code > size a bit more, use js_NewNumberValue in array_indexOfHelper. But should then foreach and friend also skip over non-existing indexes for consistency with the rest of code? It would also speedup that Array(UINT_MAX).forEach(...) from bug 310405.
Comment 8•19 years ago
|
||
Yes, I think we do want to be consistent here. indexOf and lastIndexOf aren't explicitly specified here, but the docs for forEach say that the array is treated as "dense": http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Array:forEach#Description I'm happy to rev that, though it's late in the game to get that into Firefox 1.5.
Comment 9•19 years ago
|
||
Comment on attachment 197834 [details] [diff] [review] diff -w version of last patch Very cool. r=mrbkap
Attachment #197834 -
Flags: review?(mrbkap) → review+
Updated•19 years ago
|
Whiteboard: [needs SR shaver]
| Assignee | ||
Comment 11•19 years ago
|
||
Add hole test to array_extra. /be
Attachment #198186 -
Flags: superreview?(shaver)
Attachment #198186 -
Flags: review+
| Assignee | ||
Comment 12•19 years ago
|
||
Comment 13•19 years ago
|
||
Comment on attachment 198186 [details] [diff] [review] interdiff against attachment 197832 [details] [diff] [review] sr=shaver, thanks.
Attachment #198186 -
Flags: superreview?(shaver) → superreview+
| Assignee | ||
Comment 14•19 years ago
|
||
Asa, we're doing extra reviews voluntarily, js/src requires only one level. I just checked this patch into the trunk. It should go into the 1.8 branch ASAP. /be
Assignee: general → brendan
| Assignee | ||
Updated•19 years ago
|
Attachment #198187 -
Flags: superreview+
Attachment #198187 -
Flags: review+
Attachment #198187 -
Flags: approval1.8b5?
Comment 15•19 years ago
|
||
Comment on attachment 198187 [details] [diff] [review] final patch in full approving for the branch.
Attachment #198187 -
Flags: approval1.8b5? → approval1.8b5+
Updated•19 years ago
|
Attachment #197834 -
Flags: superreview?(shaver)
| Reporter | ||
Comment 17•19 years ago
|
||
The committed "fix" added infinite loop bug for any array with holes like in Array(1).indexOf(1) oo was not in the attachment 197826 [details] [diff] [review] ;)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 18•19 years ago
|
||
I don't know if Igor was going to attach a fix, but this does the trick.
Attachment #198856 -
Flags: review?(brendan)
| Assignee | ||
Comment 19•19 years ago
|
||
Sorry about that, stupid mistake. /be
Attachment #198857 -
Flags: superreview?(shaver)
Attachment #198857 -
Flags: review?(igor3)
Attachment #198857 -
Flags: approval1.8rc1?
| Assignee | ||
Comment 20•19 years ago
|
||
mrbkap, sorry -- no IRC connection here, didn't know you were patching too. I restored the better loop structure Igor's original patch used, so I'd rather go with that. Feel free to review too. /be
Status: REOPENED → ASSIGNED
Flags: blocking1.8rc1+
| Assignee | ||
Comment 21•19 years ago
|
||
Need more testsuite coverage, obviously. And need a new brain, mine's worn out! /be
Flags: testcase?
Comment 22•19 years ago
|
||
Comment on attachment 198857 [details] [diff] [review] fix my blunder Our patches are actually equivilant, with yours simply moving the incrementing condition out of the loop header... It's a matter of style at this point.
Attachment #198857 -
Flags: review+
| Assignee | ||
Comment 23•19 years ago
|
||
(In reply to comment #22) > (From update of attachment 198857 [details] [diff] [review] [edit]) > Our patches are actually equivilant, with yours simply moving the incrementing > condition out of the loop header... It's a matter of style at this point. Yeah, that's what I said ("better loop structure"). Igor's style wins. If you can't put something in most parts of for (;;), it's better to put nothing in any part. Or so I always say! (I think ken and dmr agree... ;-) /be
Updated•19 years ago
|
Attachment #198856 -
Attachment is obsolete: true
Attachment #198856 -
Flags: review?(brendan)
| Assignee | ||
Updated•19 years ago
|
Attachment #198857 -
Flags: review?(igor3) → review?(igor.bukanov)
| Assignee | ||
Comment 24•19 years ago
|
||
Fixed on trunk (r=mrbkap suffices). Happy to get extra reviewe, but mrbkap's should suffice for the branch too. This bug should be fixed for 1.8 / Firefox 1.5. /be
| Assignee | ||
Comment 25•19 years ago
|
||
Fixed on trunk. /be
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
| Reporter | ||
Updated•19 years ago
|
Attachment #198857 -
Flags: review?(igor.bukanov) → review+
Comment 26•19 years ago
|
||
Checking in regress-310425-01.js; /cvsroot/mozilla/js/tests/js1_6/Array/regress-310425-01.js,v <-- regress-310425-01.js initial revision: 1.1 done RCS file: /cvsroot/mozilla/js/tests/js1_6/Array/regress-310425-02.js,v done Checking in regress-310425-02.js; /cvsroot/mozilla/js/tests/js1_6/Array/regress-310425-02.js,v <-- regress-310425-02.js initial revision: 1.1 done
Flags: testcase? → testcase+
Updated•19 years ago
|
Attachment #198857 -
Flags: approval1.8rc1? → approval1.8rc1+
| Assignee | ||
Comment 27•19 years ago
|
||
Oops, added fixed1.8 prematurely(!). Fixed on the branch now. /be
| Assignee | ||
Comment 28•19 years ago
|
||
Patch caused bug 315509, in spite of review and testsuite. Sorry about that. /be
| Reporter | ||
Comment 29•19 years ago
|
||
(In reply to comment #28) > Patch caused bug 315509, in spite of review and testsuite. Sorry about that. > > /be > If one passes -O3 to GCC, then it prints: jsarray.c: In function βarray_unshiftβ: jsarray.c:1117: warning: βid2β may be used uninitialized in this function Unfortunately -O or even -O2/-Os is not enough to trigger this warning with GCC 4.0.1 :(
Comment 30•19 years ago
|
||
Comment on attachment 198857 [details] [diff] [review] fix my blunder sr=shaver, too late to matter.
Attachment #198857 -
Flags: superreview?(shaver) → superreview+
You need to log in
before you can comment on or make changes to this bug.
Description
•