Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parseInt is not octal/binary by default #23

Closed
joaomoreno opened this issue May 9, 2011 · 2 comments
Closed

parseInt is not octal/binary by default #23

joaomoreno opened this issue May 9, 2011 · 2 comments

Comments

@joaomoreno
Copy link

@joaomoreno joaomoreno commented May 9, 2011

In section Always Specify the Second ‘radix’ Parameter When Using .parseInt(), it is said that

When parsing a string to an integer, it is considered good practice to specify the second 'radix' parameter - which determines to what base the string should be converted to. It is, by default, octal/binary - so you will run into some problems.

This is actually not true. ECMA-262 specifies that

The parseInt function produces an integer value dictated by interpretation of the contents of the string argument according to the specified radix. Leading white space in string is ignored. If radix is undefined or 0, it is assumed to be 10 except when the number begins with the character pairs 0x or 0X, in which case a radix of 16 is assumed. If radix is 16, number may also optionally begin with the character pairs 0x or 0X.

I do not, nevertheless, challenge the importance of always specifying the radix.

@taitems
Copy link
Owner

@taitems taitems commented May 11, 2011

Clarified (but simplified) locally pending commit.

@taitems taitems closed this May 11, 2011
@krukow
Copy link

@krukow krukow commented Jan 11, 2012

But, later in ES3:

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.

So the advice remains valid: always specify radix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.