parseInt and implicit octal constants
Allen.Wirfs-Brock at microsoft.com
Sun Feb 22 09:30:34 PST 2009
David-Sarah Hopwood wrote:
>Herman Venter wrote:
>> I appreciate that this proposal does not try to go all the way on
>octal. I am not so sure this is a good thing or that it makes the
>proposal more likely to succeed.
>I wouldn't be opposed to removing octal entirely from the spec, but
>bearing in mind the section 16 wording on syntactic extensions, even
>that would not prevent implementors from conformantly supporting it.
Actually, I don't think section 16 applies. Without the explicit allowance for implementation variance parseInt("010") would be explicitly required to produce decimal 10. It would be a violation of the specification for it to produce decimal 8. I don't believe that section 16 permits extensions that violates the rest of the specification in this manner.
Bottom line, I think we need to eliminate the waffling and decide to either explicitly require or forbid octal treatment of a leading zero string in parseInt. Ultimately, I think the decision will come down to whether we believe that disallowing octal will fix more undetected bugs (unwittingly applying parseInt (without preconditioning) to user input that happens to contain leading zeros) than it creates new ES3.1 breaking change bugs (intentional uses of parseInt that expect such octal constants). I expect the former but it is going to be hard to prove because most such bugs would be conditional upon actual user input.
Finally, there is another approach to resolving this issue. Define a new global function, parseInteger, that does the "right thing" and relegate parseInt to Annex B.
More information about the Es-discuss