4 ms·

Disclaimer: I don't know Javascript, but that's why: > ['1','7','11'].map(console.log) 1 0 [ '1', '7', '11' ] 7 1 [ '1', '7', '11' ] 11 2 [ '1', '7', '

Disclaimer: I don't know Javascript, but that's why: > ['1','7','11'].map(console.log) 1 0 [ '1', '7', '11' ] 7 1 [ '1', '7', '11' ] 11 2 [ '1', '7', '11' ] [ undefined, undefined, undefined ] > parseInt(1,0) 1 > parseInt(7,1) NaN > parseInt(11,2) 3 The correct way is: > ['1','7','11'].map(x => parseInt(x)) [ 1, 7, 11 ] same as: > ['1','7','11'].map(x => parseInt(x, 10)) [ 1, 7, 11 ]

czr 7y ago
Those are unfortunately not the same. The second one (with an explicit radix of 10) is correct; the first is not (or is at least a bit riskier). See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#Description https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... (ctrl+f for "always").
- notus 7y ago
  In most browser implementations (at least all the ones we develop for) it would assume a radix of 10 for those values specifically.
  - deleted 7y ago
    [deleted]
- acdha 7y ago
  But see also https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#Octal_interpretations_with_no_radix https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... and especially https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... — that comment is increasingly stale unless you support browsers which are no longer supported by their vendors like IE8.
  - czr 7y ago
    Good point. I've edited my comment to be more qualified.
    - acdha 7y ago
      The web is a fascinating study of advice that changed over time: there’s something like a half-decade window where the two argument form became common, with unsafe usage before and safe usage after.
- swang 7y ago
  this is a relic from issues in ie8, and you no longer need to do this if you're not supporting ie8. hell even if you use ie8 in almost 99% of cases you won't need to bother.
btbuildem 7y ago
Thank you! The article failed to provide the conclusion, ie, how to make it work as one would expect were one not steeped in JS quirks
waynecochran 7y ago
What does parseInt work with a radix of 0 but not 1? Neither really makes any sense.
- jandrese 7y ago
  0 is a special case where the parser tries to guess based on how the number is formatted. 1 just doesn't make sense at all. Using 0 is the source of many interesting bugs, like when someone puts in an IP address like so: 192.168.010.001 and the client tells you it can't connect (to 192.168.8.1).
  - tylerhou 7y ago
    As of ES5 010 must be parsed as 8 if you pass in a radix of 0.
    - WorldMaker 7y ago
      Because leading 0 implies octal (Base-8). Interestingly, this is also the standard interpretation of IPv4 addresses in that form, where each delimited number [octet] in an IP address that start with a leading 0 should be read as octal. (That behavior contrasts interestingly with IPv6 where the numbers [segments] are only supposed to ever be hexadecimal (Base-16) and leading zeroes are to be ignored.)
      - tylerhou 7y ago
        (I'm trying to say that this behavior was removed in modern browsers. The only time when modern browsers are allowed to parse strings as a base other than base-10 when the second argument to parseInt is 0 or undefined is when the string starts with 0x or 0X, at which point the browser must parse it as base-16.)
        WorldMaker 7y ago
        I caught that if it wasn't clear; it wasn't a direct reply but a reply to the whole thread. I was just pointing out why that original behavior existed in the first place and how funny it is that that behavior in the given example is actually more technically correct because IPv4 addresses are supposed to do that.

czr 7y ago

Those are unfortunately not the same. The second one (with an explicit radix of 10) is correct; the first is not (or is at least a bit riskier). See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#Description https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... (ctrl+f for "always").

notus 7y ago
In most browser implementations (at least all the ones we develop for) it would assume a radix of 10 for those values specifically.
- deleted 7y ago
  [deleted]
acdha 7y ago
But see also https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#Octal_interpretations_with_no_radix https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... and especially https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... — that comment is increasingly stale unless you support browsers which are no longer supported by their vendors like IE8.
- czr 7y ago
  Good point. I've edited my comment to be more qualified.
  - acdha 7y ago
    The web is a fascinating study of advice that changed over time: there’s something like a half-decade window where the two argument form became common, with unsafe usage before and safe usage after.
swang 7y ago
this is a relic from issues in ie8, and you no longer need to do this if you're not supporting ie8. hell even if you use ie8 in almost 99% of cases you won't need to bother.

btbuildem 7y ago

Thank you! The article failed to provide the conclusion, ie, how to make it work as one would expect were one not steeped in JS quirks

waynecochran 7y ago

What does parseInt work with a radix of 0 but not 1? Neither really makes any sense.

jandrese 7y ago
0 is a special case where the parser tries to guess based on how the number is formatted. 1 just doesn't make sense at all. Using 0 is the source of many interesting bugs, like when someone puts in an IP address like so: 192.168.010.001 and the client tells you it can't connect (to 192.168.8.1).
- tylerhou 7y ago
  As of ES5 010 must be parsed as 8 if you pass in a radix of 0.
  - WorldMaker 7y ago
    Because leading 0 implies octal (Base-8). Interestingly, this is also the standard interpretation of IPv4 addresses in that form, where each delimited number [octet] in an IP address that start with a leading 0 should be read as octal. (That behavior contrasts interestingly with IPv6 where the numbers [segments] are only supposed to ever be hexadecimal (Base-16) and leading zeroes are to be ignored.)
    - tylerhou 7y ago
      (I'm trying to say that this behavior was removed in modern browsers. The only time when modern browsers are allowed to parse strings as a base other than base-10 when the second argument to parseInt is 0 or undefined is when the string starts with 0x or 0X, at which point the browser must parse it as base-16.)
      - WorldMaker 7y ago
        I caught that if it wasn't clear; it wasn't a direct reply but a reply to the whole thread. I was just pointing out why that original behavior existed in the first place and how funny it is that that behavior in the given example is actually more technically correct because IPv4 addresses are supposed to do that.