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
Status: UNCONFIRMED
:
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
:
Mentors:
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:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


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

Description 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 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
Comment 1 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 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 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 Eli Grey (:sephr) 2010-09-05 12:21:00 PDT
Completely agree with you. So it's going to be WONTFIX?
Comment 5 Masataka Yakura 2012-01-25 08:56:42 PST
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.
Comment 6 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 Masataka Yakura 2012-08-13 22:17:24 PDT
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 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 Š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 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 rodolfo.3 2014-08-08 05:56:14 PDT
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"...

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