Last Comment Bug 510415 - parseInt should interpret numbers with leading 0s as decimal, not octal
: parseInt should interpret numbers with leading 0s as decimal, not octal
Product: Rhino
Classification: Components
Component: Core (show other bugs)
: other
: All All
-- enhancement with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
Blocks: 489326
  Show dependency treegraph
Reported: 2009-08-13 20:40 PDT by rspeyer
Modified: 2014-08-08 05:56 PDT (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

removed logic for interpreting a leading 0 as => octal (1.05 KB, patch)
2009-08-13 20:42 PDT, rspeyer
no flags Details | Diff | Splinter Review

Description User image rspeyer 2009-08-13 20:40:12 PDT
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

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
Comment 1 User image rspeyer 2009-08-13 20:42:46 PDT
Created attachment 394448 [details] [diff] [review]
removed logic for interpreting a leading 0 as => octal

from the parseInt builtin function only.
Comment 2 User image Eli Grey (:sephr) 2009-12-20 08:29:43 PST
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.
Comment 3 User image Jeff Walden [:Waldo] (remove +bmo to email) 2010-09-05 12:17:38 PDT
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 User image Eli Grey (:sephr) 2010-09-05 12:21:00 PDT
Completely agree with you. So it's going to be WONTFIX?
Comment 5 User image Masataka Yakura 2012-01-25 08:56:42 PST
IE9 (in IE9 standards mode) and JavaScriptCore follows ES5.

JSC doesn't change its behavior on the strictness. Not sure about how IE9 does.
Comment 6 User image Jeff Walden [:Waldo] (remove +bmo to email) 2012-01-25 10:23:21 PST
Interesting.  I knew about the former, but the latter is much newer.  In light of that, perhaps we should be changing, possibly...
Comment 7 User image Masataka Yakura 2012-08-13 22:17:24 PDT
- 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.
Comment 8 User image Justin Warkentin 2013-04-09 13:10:03 PDT
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 User image Šime Vidas 2013-07-13 07:18:49 PDT
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.
Comment 10 User image Jeff Walden [:Waldo] (remove +bmo to email) 2013-07-13 11:22:40 PDT
It only changed a few months ago or so, in bug 786135.
Comment 11 User image rodolfo.3 2014-08-08 05:56:14 PDT
It still a problem in Firefox. Just typing "08" into the console gets an error:

Not sure about the spec: it's specific for "parseInt" or for all uses of numbers starting with "0"...

Note You need to log in before you can comment on or make changes to this bug.