Differences between version #9426 and #9427

30c30,43
< Std.parseInt treats inputs that start with 0 as octal.  Accordingly, Std.parseInt("09") will return 0 in many browsers.  This is appropriate according to a given ecmascript specification, but is a common source of errors for numeric parsing.  For an overview of the situation, see [[http://www.w3schools.com/jsref/jsref_parseInt.asp|the parseInt documentation]] and [[http://stackoverflow.com/questions/2547836/why-doesnt-an-octal-literal-as-a-string-cast-to-a-number|this stackoverflow response]] All other Haxe targets use native parseInt implementations that parse "09" as 9.
\ No newline at end of file
---
> Std.parseInt treats inputs that start with 0 as octal.  Accordingly, Std.parseInt("09") will return 0 in many browsers.  This is appropriate according to a given ecmascript specification, but is a common source of errors for numeric parsing.  For an overview of the situation, see [[http://www.w3schools.com/jsref/jsref_parseInt.asp|the parseInt documentation]] and [[http://stackoverflow.com/questions/2547836/why-doesnt-an-octal-literal-as-a-string-cast-to-a-number|this stackoverflow response]] All other Haxe targets use native parseInt implementations that parse "09" as 9.
> 
> Suggested workarounds include stripping leading zeroes from strings in javascript for conversions:  
> 
> <code haxe>
> 	public static function parseInt(str:String):Int{
> 		#if js
> 			str =	~/^0*(\d)/.replace(str, '$1');
> 			untyped return __js__('parseInt')(str);
> 		#else
> 			return Std.parseInt(str);
> 		#end
> 	}
> </code>
\ No newline at end of file