Erik Arvidsson (2014-10-03T14:04:28.000Z)
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.



On Fri, Oct 3, 2014 at 9:43 AM, Mathias Bynens <mathiasb at opera.com> wrote:

> Thanks for once again putting this together, Rick!
>
> On Fri, Oct 3, 2014 at 3:22 PM, Rick Waldron <waldron.rick at gmail.com>
> wrote:
> > ## 4.4 Number('0b0101'). NaN or not?
> > (Erik Arvidsson)
> >
> > EA: Previous discussion:
> >
> https://github.com/rwaldron/tc39-notes/blob/c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2014-04/apr-9.md#46-updates-to-parseint
> >
> > Should `Number` be able to parse the string "0b0" or "0o1"
> >
> > (Discussion of people (ab)using Number for converting user input and
> whether
> > this should affect things.)
> >
> > Yes.
> >
> > #### Conclusion/Resolution
> >
> > - Use spec-internal `ToNumber` via userland `Number` called as a function
> > will convert (ie `Number('0b101') === 5)`.
> > - Upholding previous consensus on `parseInt`
>
> I don’t understand this reasoning. Making `parseInt` understand the
> new syntax was considered a security hazard, but for `Number` we can
> somehow get away with it? Any more information on the disconnect?
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141003/97d29bea/attachment.html>
domenic at domenicdenicola.com (2014-10-15T18:34:43.215Z)
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.