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.
Also, that document says the behavior is nonstandard, so I don't even see how you can say it's behaving as specified.