Sept 23 2014 Meeting Notes

Allen Wirfs-Brock allen at
Fri Oct 3 08:13:00 PDT 2014

On Oct 3, 2014, at 7:35 AM, Rick Waldron wrote:

> On Fri, Oct 3, 2014 at 10:04 AM, Erik Arvidsson <erik.arvidsson at> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list