switch(+(Array(2147483647))){default:}
Firefox produces a slow script warning on this example, we don't because Array.toString, etc are native code. I'm thinking that a hard cap on toString'd array size + time out checks periodically in the toString conversion and what not would do the trick. Anyone have any better ideas?
Hmmm, it occurs to me that relying on the slow script dialog to kill execution won't work in the shell. Also the code has a null check of the data for the buffer (to catch OOM) but vector growing uses the crashing version of malloc Is it possible to make a vector use the non-throwing version?
Also, for reference a JS version of Array.toString solves the hang by implicitly having timeout checks. unfortunately it's 35% slower than the C++ version. For compact (non-sparse) arrays it beats firefox though :D
(In reply to comment #2) > Is it possible to make a vector use the non-throwing version? Sure it's possible, but it changes the contract with clients. What behavior are you suggesting when allocation fails? How will we update all the clients to work with the new behavior?
(In reply to comment #4) > (In reply to comment #2) > > Is it possible to make a vector use the non-throwing version? > > Sure it's possible, but it changes the contract with clients. > > What behavior are you suggesting when allocation fails? How will we update all > the clients to work with the new behavior? > No i dind't mean in general --i was asking (somewhat vaguely i guess) whether there a template parameter or something that control which malloc a vector would use.
(In reply to comment #5) > No i dind't mean in general --i was asking (somewhat vaguely i guess) whether > there a template parameter or something that control which malloc a vector > would use. Sure, we could. But then we'd still need to define what various operations do when allocation fails when that template parameter was set. It might be better to have a completely separate class template. We could still share implementation with Vector.
*** Bug 13638 has been marked as a duplicate of this bug. ***
This test case is equivalent to Array(2147483647).toString(). This completes with appropriate performance. Works for me.