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)
Rhino Graveyard
Core
Tracking
(Not tracked)
RESOLVED
INACTIVE
People
(Reporter: rspeyer, Unassigned)
References
Details
Attachments
(1 file)
1.05 KB,
patch
|
Details | Diff | Splinter Review |
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 2•15 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.
Comment 3•14 years ago
|
||
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•14 years ago
|
||
Completely agree with you. So it's going to be WONTFIX?
Comment 5•12 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.
Comment 6•12 years ago
|
||
Interesting. I knew about the former, but the latter is much newer. In light of that, perhaps we should be changing, possibly...
Comment 7•12 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•11 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•11 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.
Comment 10•11 years ago
|
||
It only changed a few months ago or so, in bug 786135.
Comment 11•10 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"...
Comment 12•5 years ago
|
||
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.
Description
•