The parseInt() function parses an input string (e.g, "89ab") associated to some radix (e.g, 16) and returns the corresponding integer in the specified base. Here we would get the number 35243, i.e 0x89AB.

The generic syntax is parseInt(str,radix), where radix can range from 2 to 36. So if you need to parse the decimal representation of a number, just pass in radix=10—that's anyway the implied radix, unless str starts with 0 or 0x. Leading and trailing spaces are allowed in the input string, and any character that is not a valid digit in the specified radix will break the parser at this location and make parseInt return the integer parsed up to that point.

So far so good. But ExtendScript has a serious problem with radix>10. It wrongly interprets character codes in the range [58, 58+radix-11] as valid digits. Here are some of the outcomes we observed:

// parseInt bug in ExtendScript (all versions)
 
parseInt( "a?",16 ) === 175    // Should return 10
parseInt( "=", 16 ) === 13     // Should return NaN
parseInt( ":", 11 ) === 10     // Should return NaN
 
// etc.
 

This problem becomes critical if your script has to work with arbitrary strings (text stream, user inputs…) and provides no filtering mechanism. The best solution—IMHO—is to make secure and overwrite parseInt in the [[global]] scope. A cool thing is that you can keep a copy of the original function, then invoke it once the arguments have been properly sanitized.

From version 1.81117, IdExtenso automatically provides a patch that both fixes the bug and makes parseInt ECMA2018-compliant. In particular, the '0' prefix is no longer assumed to introduce an octal representation.

Links:
— Patch code: github.com/indiscripts/IdExtenso/…/core/Ext/$$.global.jsxinc
— Test it: ParseIntFix.jsx
— IdExtenso: github.com/indiscripts/IdExtenso