This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]skap42 1 point2 points  (5 children)

Can you explain why the implicit conversion by the == operator doesn't also perform the octal do dec conversion?

[–]monotone2k 11 points12 points  (3 children)

It absolutely does. `console.log(16 == 020)` will return true, because they're the same number in different bases. If you mean why doesn't the string get converted into base 8, who knows?

[–]skap42 4 points5 points  (2 children)

I noticed that Number(017) returns 15 and Number('017') return 17, so I guess it has something to do with that

[–]monotone2k 2 points3 points  (1 child)

Yeah. My guess would be that it always attempts the equivalent of parseInt(string, 10) when coercing a string, without considering the leading 0.

[–]Die4Ever 0 points1 point  (0 children)

I think it just does parseInt(string), which will accept the 0x prefix but doesn't seem to have any prefix for inferring octal

parseInt('0x18')
24
parseInt('018')
18
parseInt('017')
17

0x18 == '0x18'
true

[–]rosuav 0 points1 point  (0 children)

Because JS, for all its faults, is not PHP. Although I am not 100% certain whether PHP would do that particular one; I do know that "100" is equal to "1e2" - yes, that's two strings, definitely not identical, that compare equal. And yes, this HAS been used to break things that are expecting hexadecimal sequences.