On Oct 3, 2014, at 7:35 AM, Rick Waldron wrote:
>
>
> On Fri, Oct 3, 2014 at 10:04 AM, Erik Arvidsson <[email protected]>
> wrote:
> Number has always been able to handle the full NumericLiteral. In ES5.1 it
> can handle '-1', '-0', '0xff', '0XFF', '1e2', '-1E-2', 'Infinity'. Breaking
> that consistency was unwanted.
>
> This means that it is a change to existing semantics. We think we can get
> away with it though.
>
> ES5.1: Number('0b10') === NaN
> ES6: Number('0b10') === 2
>
> I don't know why Waldemar thought this would be a security issue for
> parseInt? I wasn't at that meeting and the notes do not cover that.
>
> The security concern was for validating user input and any reliance on the
> existing semantics being broken.
parseInt: "parseInt may interpret only a leading portion of string as an
integer value; it ignores any code units that cannot be interpreted as part of
the notation of an integer, and no indication is given that any such code units
were ignored."
ES5: parseInt("0b10") //0
ES6 as specified: parseInt("0b10") //0
ES6 if new forms recognized: parseInt("0b10") //2
Number: "ToNumber applied to Strings applies the following grammar to the
input String interpreted as a sequence of UTF-16 encoded code points. If the
grammar cannot interpret the String as an expansion of StringNumericLiteral,
then the result of ToNumber is NaN."
ES5: Number("0b10") //NaN
ES6: Number("0b10") //2_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
