parseInt should interpret numbers with leading 0s as decimal, not octal

UNCONFIRMED
Unassigned

Status

Rhino
Core
--
enhancement
UNCONFIRMED
8 years ago
3 years ago

People

(Reporter: rspeyer, Unassigned)

Tracking

(Blocks: 1 bug)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4
Build Identifier: Rhino 1.7 release 2 2009 03 22

As per 15.1.2.2.

ES5 removes octal literals from the language, but provides a non-normative description for backwards compatibility (Annex B.1). Should we remove octal literals from Rhino too? If not, is there any issue with having the parseInt function differ from the language parser?

Reproducible: Always
(Reporter)

Updated

8 years ago
Blocks: 489326
(Reporter)

Comment 1

8 years ago
Created attachment 394448 [details] [diff] [review]
removed logic for interpreting a leading 0 as => octal

from the parseInt builtin function only.

Comment 2

8 years ago
I'm a little confused with Annex B.1 but I think we should not drop leading 0 octal support in parseInt. This would break the processing.js library, which uses parseInt to parse Java number literals without assuming any base. Of course, it would be trivial to fix processing.js so maybe leading 0 octals shouldn't be supported.
SpiderMonkey ended up deliberately (continuing to) violate the ES5 spec on this point.  We were going to make parseInt behavior depend on the caller's strictness for a bit with bug 577536, but then we reverted in bug 583925 (partly because that would make self-hosting behavior a bit tricky (e.g. is the self-hosted code strict mode or not, and does that affect parseInt's behavior?  would need implementation magic to do it, in that case).  I'd like to kill implicit octal, but I really don't think the web could support that change (and I'm even one of the more aggressive backward-compat breakers among SpiderMonkey hackers).

Comment 4

7 years ago
Completely agree with you. So it's going to be WONTFIX?

Comment 5

6 years ago
IE9 (in IE9 standards mode) and JavaScriptCore follows ES5.
http://msdn.microsoft.com/en-us/library/x53yedee%28VS.85%29.aspx
http://trac.webkit.org/changeset/103922

JSC doesn't change its behavior on the strictness. Not sure about how IE9 does.
Interesting.  I knew about the former, but the latter is much newer.  In light of that, perhaps we should be changing, possibly...

Comment 7

5 years ago
Updates:
- Safari 6 has shipped with the new JSC and now conforms to ES5.
- V8 follows JSC and has landed support. Cr23 will ship with the new behavior. http://code.google.com/p/v8/source/detail?r=12273

Comment 8

4 years ago
Chrome follows the spec. I find it odd that in the MDN documentation is talks about the spec and even mentions that ES5 forbids interpreting strings starting with '0' as octal, and yet nowhere does it mention that FF doesn't follow the spec. With most of the modern browsers following the spec, why doesn't FF do so? If it breaks somebody's site, they can easily do a hack to return to the old (pre-ES5) behavior like this:

(function() {
  var origParseInt = parseInt;
  parseInt = function(num, radix) {
    if(num.toString().substr(0, 1) == '0') {
      radix = 8;
    }
    return origParseInt(num, radix);
  }
})();

If FF isn't going to follow the spec it should at least document that fact.

Comment 9

4 years ago
I just checked parseInt('08') in latest Firefox (version 22, Windows) and it evaluates to 8. So, Firefox *does* follow the ES5 spec now. Not sure why this wasn't mentioned in this bug.
It only changed a few months ago or so, in bug 786135.

Comment 11

3 years ago
It still a problem in Firefox. Just typing "08" into the console gets an error:
http://imgur.com/Qxeh03j

Not sure about the spec: it's specific for "parseInt" or for all uses of numbers starting with "0"...
You need to log in before you can comment on or make changes to this bug.