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.
Allen
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
