583925 - parseInt should not use caller's strictness in choosing radix

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jim Blandy :jimb]

At the moment, the JavaScript parseInt function consults its scripted caller's strictness to decide whether to treat strings with leading zeros as octal (if the radix was not passed to the function explicitly). This behavior was introduced deliberately, as part of the fix for bug 577536.

Caller-sensitivity is extremely bad practice.
- It makes it difficult to predict how functions will behave when passed as values.
- It interferes with tail call optimization.
- It creates behavior that cannot be expressed in JavaScript; for example, ["0377"].map(parseInt) will behave differently if 'map' is implemented is JS instead of C++.

There are cases where ES5 specifies caller-sensitive behavior, but in each case, the intent is actually to *discourage* inappropriate caller/callee interactions:
- The 'eval' function behaves differently depending on whether it is called directly or indirectly, but the intent there is to encourage migration to code where eval cannot create bindings in its caller's environment.
- The 'Function.prototype.caller' function is sensitive to the strictness of its caller, but again, the intention is to forbid the use of 'caller' to mess with strict mode callers.

Finally, in our solutions to ugly HTML5 corner cases, we are also moving away from caller sensitivity: bug 521670 suggests disabling the 'document.all' detection in strict mode code, which is essentially another form of caller detection.

ES5, as written, requires parseInt not to treat strings with leading zeros as octal when no radix is passed explicitly. However, JSC plans to ignore that direction, and leave parseInt's behavior unchanged --- it will continue to infer octality.

Comment 1

[Jim Blandy :jimb]

Attachment: parseInt should not depend on its caller's strictness.

Comment 2

[Jeff Walden [:Waldo]]

Comment on attachment 462272 [details] [diff] [review]
parseInt should not depend on its caller's strictness.

>diff --git a/js/src/jsnum.cpp b/js/src/jsnum.cpp

>              * Non-standard: ES5 requires that parseInt interpret leading-zero
>              * strings not starting with "0x" or "0X" as decimal (absent an
>              * explicitly specified non-zero radix), but we continue to
>+             * interpret such strings as octal.

Add "per ES3" (and maybe "and the web") at the end here.

Comment 3

[Jim Blandy :jimb]

http://hg.mozilla.org/tracemonkey/rev/898ab54a0ce9

Comment 4

[Nicholas Nethercote [inactive]]

This patch is causing two trace-test failures:  parseIntTests.js and
strictParseIntOctal.js.

Comment 5

[Jeff Walden [:Waldo]]

http://hg.mozilla.org/tracemonkey/rev/ee836f19c4e7

Comment 6

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/898ab54a0ce9

Comment 7

[Masatoshi Kimura [:emk]]

IE9 beta treats strings with leading zeros as decimal in IE9 mode.
Is the web compat still a problem?

Comment 8

[Masatoshi Kimura [:emk]]

JavaScriptCore also treats leading zeros as decimal now.
http://trac.webkit.org/changeset/103922