Notifications

19 views

Description

In a scoped application on Istanbul, using 'ES5 Standards Mode', the javascript parseInt function does not treat the number specified in its first string argument as octal if the argument starts with one or more leading '0's.  Any leading 0s are ignored and the string is interpreted as being in base 10. This is the correct behaviour.
 
After upgrading to Jakarta or later, the parseInt function does interpret the first argument as octal if it starts with a leading '0', and returns a decimal value from the conversion from octal, rather than the decimal value with the leading 0s ignored.
 
From:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#Octal_interpretations_with_no_radix
 
"Although discouraged by ECMAScript 3 and forbidden by ECMAScript 5, many implementations interpret a numeric string beginning with a leading 0 as octal."
 
ECMA 5.1 - see 15.1.2.2:
https://www.ecma-international.org/ecma-262/5.1/#sec-15.1.2
 
"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."
 
 

Steps to Reproduce

On an Istanbul instance in sys.scripts.do run the following with the scope choice set to 'global':

var number = '000000020920051';
gs.info('Number parsed without radix/base: ' + parseInt(number));
gs.info('Number parsed as octal: ' + parseInt(number,8));
gs.info('Number parsed as decimal: ' + parseInt(number,10));

the output is:
*** Script: Number parsed without radix/base: 16
*** Script: Number parsed as octal: 16
*** Script: Number parsed as decimal: 20920051

The number is interpreted as octal and converted to 16 (everything from the 9 onwards is ignored as 9 isn't valid in octal).

Switching the scope to 'sn_devstudio' (uses ES5 Standards Mode) the output is:
sn_devstudio: Number parsed without radix/base: 20920051
sn_devstudio: Number parsed as octal: 16
sn_devstudio: Number parsed as decimal: 20920051

Note the difference in the first result - the leading 0s have been ignored by parseInt and the decimal value has been returned.

Repeat the same test on Jakarta through to London and the results are:

global:
*** Script: Number parsed without radix/base: 16
*** Script: Number parsed as octal: 16
*** Script: Number parsed as decimal: 20920051

sn_devstudio:
sn_devstudio: Number parsed without radix/base: 16
sn_devstudio: Number parsed as octal: 16
sn_devstudio: Number parsed as decimal: 20920051

Note that the results are identical to each other and the leading 0s have resulted in the number being interpreted as octal in both cases.

Workaround

The workaround is to specify the radix/base when using parseInt, therefore if the value being converted needs to be interpreted as a decimal then instead of:

parseInt(number);

use:

parseInt(number,10);

 

This problem has been fixed in Madrid release. If you are able to upgrade, review the Fixed In or Intended Fix Version fields to determine whether any versions have a planned or permanent fix.


Related Problem: PRB1300391

Seen In

There is no data to report.

Fixed In

Madrid

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2019-06-24 08:01:07
Published:2019-06-24