Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

According to the ECMAScript spec the integer part of a decimal number should be either zero or start with a non-zero digit. A hexadecimal value should start with 0x.

Javascript, in the major browsers, extends EMCAScript to include octal numbers. These are determined by having a sequence of digits (from 0 to 7 inclusive) start with a zero.

Given these facts, my naive implementation of a javascript interpreter would probably parse integers a bit like this:

if first_char in [1-9] then
    parse_input_as_decimal()
else if first_char is 0 then
    if second_char is 'x' then
        parse_input_as_hexadecimal()
    else if second_char in [1-7] then
        parse_input_as_octal()
    else
        parse_input_as_zero()

However the web browsers seem to act slightly weird in that if a number beginning with zero contains the digits 8 or 9 then it reads it as a valid decimal. This can lead to oddities, especially when using a decimal point or exponent. Some examples:

011 // is octal
0011 // is octal
019 // is decimal
0091 // is decimal
011.0 // throws an error
019.0 // is decimal
011e5 // throws an error
019e5 // is decimal

My question is why do they behave like this? Is it just some quirk of history? Or is there a good reason? Is it written in some spec somewhere? Will this ever change?

I know this is a bit arcane and few people use octals in javascript these days, but I'm curious.

share|improve this question
    
Related from SO - Javascript, why treated as octal - though the reason ultimately is "that is the way many other C like syntax languages do it." –  MichaelT Jun 8 '13 at 23:41
    
It was a silly overload to add to a higher level language meant to be accessible to a wide variety of skill-levels. I'm not embarrassed to admit that it ruined close to a day of my life. –  Erik Reppen Jun 13 '13 at 15:02
    
Note: on the above I mistakenly thinking of the parseInt/parseFloat ocal overloads. –  Erik Reppen Jun 17 '13 at 18:33
add comment

1 Answer 1

Quirk:'strict mode' gets rid of this behavior, I think it was a non standard behavior that a couple browsers implemented but I'm not 100% (about it being non-standard, I am sure about it being removed from strict JavaScript)

share|improve this answer
    
The '0...' overload is also no longer present in modern browsers (well, Chrome and I believe FF at least) and set to not act that way in the more recent specs. It was a doozy of a bug for every JS dev splitting out dollars and cents from strings in the html. Definitely a "bad part" we could all agree on. –  Erik Reppen Jun 13 '13 at 15:00
    
0011 comes up as 9 in the console of chrome 27 (aka up to date version I am using right now) –  Calvin Jun 14 '13 at 23:27
    
With what method? –  Erik Reppen Jun 14 '13 at 23:34
    
open up dev tools, go to console, type 0011, response is 9 –  Calvin Jun 17 '13 at 10:03
    
Ah, I was thinking of the parseInt and parseFloat overloads where '08' gave you 0 or '010' gave you 8. stackoverflow.com/questions/850341/… –  Erik Reppen Jun 17 '13 at 18:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.