parseInt should not use caller's strictness in choosing radix

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: jimb, Assigned: jimb)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed-in-tracemonkey])

Attachments

(1 attachment)

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.
Assignee: general → jim
Attachment #462272 - Flags: review? → review?(jwalden+bmo)
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.
Attachment #462272 - Flags: review?(jwalden+bmo) → review+
http://hg.mozilla.org/tracemonkey/rev/898ab54a0ce9
Status: NEW → ASSIGNED
Whiteboard: [fixed-in-tracemonkey]
This patch is causing two trace-test failures:  parseIntTests.js and
strictParseIntOctal.js.
http://hg.mozilla.org/mozilla-central/rev/898ab54a0ce9
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
IE9 beta treats strings with leading zeros as decimal in IE9 mode.
Is the web compat still a problem?
JavaScriptCore also treats leading zeros as decimal now.
http://trac.webkit.org/changeset/103922
You need to log in before you can comment on or make changes to this bug.