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.
Numeric constants starting with 0 define octal values in many languages, hell they do so even in Java. Does that mean all those languages are buggy? I'd say you're going to find features that don't make sense to anyone who's never used them...pretty much anywhere.
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.
I'd say that the entire concept of octal literals is a bug, yes. (It's almost _entirely_ useless, a leftover from the days of yore. When for Christmas, we got naked, wrapped ourselves in punch tape versions of the latest "editor", and danced around the Christmas tree while setting the line printer on fire. But I digress.. ;)
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.
I really don't see how it makes perfect sense for a value which is not by any stretch of imagination a valid octal number to be interpreted as an octal number. Imagine if `parseInt('foo')` gave 38274 — would you also think that made perfect sense?
Also, that document says the behavior is nonstandard, so I don't even see how you can say it's behaving as specified.
I really don't see how it makes perfect sense for a value which is not by any stretch of imagination a valid octal number to be interpreted as an octal number. Imagine if `parseInt('foo')` gave 38274 — would you also think that made perfect sense?
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".
The standard encourages implementations to interpret numbers as decimal, and it doesn't say to interpret non-numbers (such as octal 9, which is what the number would have to be if you were taking "0" as the octal prefix) as 0. I don't see how it's necessary for compliance or even sensible to interpret numbers that don't exist in octal as octal 0, except that it's a quirk older implementations had and new ones don't want to break compatibility.
Following a spec is not a valid excuse for it not being a bug. Specs have bugs too; sometimes they're even designed in, deliberately, to make companies not look bad, or to preserve backward compatibility.
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.
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.