Comments on: Some differences between JavaScript engines

By: pd

pd — Thu, 25 Dec 2008 12:23:02 +0000

I’d really like to see this sort of analysis in a complete sense. I’m thinking a compatibility table like PPK’s quirksmode but instead of listing the different browser behaviours in relation to JavaScript events, common coding patterns and the varying behaviours of the different JS engines, would be a great benefit to developers.

By: Ajaxian » Playing with a fuzzy monkey; Helping JITs improve

Ajaxian » Playing with a fuzzy monkey; Helping JITs improve — Wed, 24 Dec 2008 10:29:23 +0000

[...] then put his fuzzer to work to find differences between Spidermonkey and JavaScriptCore. Interesting [...]

By: Ian Hickson

Ian Hickson — Wed, 24 Dec 2008 08:29:08 +0000

Please file bugs where appropriate — either with WebKit, or Mozilla, or with the ECMAScript committee if the spec is vague. :-)

By: Jeff Walden

Jeff Walden — Wed, 24 Dec 2008 04:49:50 +0000

“nuls aren’t allowed in the grammar for converting a string to a number”, sorry.

By: Jeff Walden

Jeff Walden — Wed, 24 Dec 2008 04:42:50 +0000

Jesse points out it’s not new 4, really new Math.sqrt with an argument, so that’s just the same thing as new ({}.toString). My mistake reading too quickly!

By: Jeff Walden

Jeff Walden — Wed, 24 Dec 2008 04:34:13 +0000

Either behavior for early-error is fine (16, attempting to call PutValue).

SpiderMonkey is correct for the first instanceof, because native objects don’t implement [[HasInstance]] unless they’re functions. The second behavior, as far as I can tell, can go either way per the last paragraph of 15.1.2.1.

new 4 is a SpiderMonkey bug (4 is not an Object). new ({}.toString) is ambiguous, I think, because functions only acquire [[Construct]] if they’re declared in a script that’s executed, but it’s not specified that natively-implemented functions don’t have [[Construct]]. new eval goes either way for the same reason as the previous paragraph.

The first conversion test is JavaScriptCore’s bug; nuls aren’t allowed in strings. I bet they’re stopping stringification of the number after hitting a , in which case an empty string is 0. The latter case any radix but 10 in the range 2 to 36 is implementation-defined what’s returned, except that it’s a string.

const is extension-land, no correct behavior yet.

The first other difference is SpiderMonkey following the spec as it currently stands; I think that’s changing in ES3.next. The second is underspecified, in that nothing says only Function objects implement [[Call]].