This is an evil bug in Javascript
parseInt('06') // 6
parseInt('07') // 7
parseInt('08') // 0
parseInt('09') // 0
parseInt('10') // 10
parseInt should really return NaN for '08', '09' etc
parseInt('06') // 6
parseInt('07') // 7
parseInt('08') // 0
parseInt('09') // 0
parseInt('10') // 10
parseInt should really return NaN for '08', '09' etc
It's not a bug, behaves like specified:
https://developer.mozilla.org/en/JavaScript/Reference/Global...
If parseInt encounters a character that is not a numeral in the specified radix, it ignores it and all succeeding characters and returns the integer value parsed up to that point. parseInt truncates numbers to integer values. Leading and trailing spaces are allowed.
[...]
For this reason always specify a radix when using parseInt.
It does _not_ make perfect sense to anybody who's never used octal. That is presumably the vast majority of anybody born past, say, 1980.
As such, it _is_ a bug in the sense that it violates expectations. It's just a bug in the spec, not in the code.
I would think the issue is more the behavior of "parse as much as you can until you can't, and return what you got so far", which is what causes the unexpected result of returning 0 instead of bailing out. However that apparently wasn't fixed in ECMAScript 5, presumably for backwards compatibility.
But fine, if I at least got "undefined" (well, null) as a result of parsing an invalid octal string, it'd be not quite as bad. So yes, if we talk root causes, you put your finger on that. The anachronism of octal parsing just exposes it.
Also, that document says the behavior is nonstandard, so I don't even see how you can say it's behaving as specified.
The page specifically says that if radix is unspecified, then "If the input string begins with "0", radix is eight (octal)."
The page also says "If the first character cannot be converted to a number, parseInt returns NaN." so your example is also perfectly defined to return NaN (and thus bogus).
Also, that document says the behavior is nonstandard, so I don't see even how you can say it's behaving as specified.
It's a weird wording in that webpage, because ECMAScript 3 allows it:
"When radix is 0 or undefined and the string's number begins with a 0 digit not followed by an x or X, then the implementation may, at its discretion, interpret the number either as being octal or as being decimal. Implementations are encouraged to interpret numbers in this case as being decimal."
ECMAScript 5 no longer allows it. Given that your code isn't necessarily processed by an ECMAScript 5 compliant JavaScript engine, it's indeed behaving as specified. Maybe instead of "non-standard" a better word would have been "behavior varies between implementations".
It's not. That isn't what happens, either. The parser stops when it sees the 9.
For a parser to ignore trailing garbage after it has parsed as far as it can is usually a sign of a poor-quality parser. On topic: an odd feature of Pascal is that all text following the final 'end' '.' in the file is ignored. But good quality compilers still issue a warning.
User enters 08 for August, even returning NaN would be a mistake.
parseInt('08', 10) // => 8
Much worse than this one obviously, caused if I recall by not checking how strtol set endptr.