Closed Bug 510415 Opened 15 years ago Closed 5 years ago

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

Categories

(Rhino Graveyard :: Core, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED INACTIVE

People

(Reporter: rspeyer, Unassigned)

References

Details

Attachments

(1 file)

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
Blocks: 489326
from the parseInt builtin function only.
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).
Completely agree with you. So it's going to be WONTFIX?
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...
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
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.
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.
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"...

Closing. Bug management is now done here:
https://github.com/mozilla/rhino

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: