Differences between version #9428 and #9429

30c30
< 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.
---
> The original parseInt for js targets treats inputs that start with 0 as octal by default.  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.  In order to prevent this behavior in standard javascript, it is necessary to specify a base as a second argument of the parseInt function (e.g. parseInt("09", 10)).  However, the Haxe version of this function does not provide a second argument, so this solution isn't appropriate in Haxe code.  All other Haxe targets use native parseInt implementations that parse "09" as 9.
32c32
< Suggested workarounds include stripping leading zeroes from strings in javascript for conversions:  
---
> Suggested workarounds include stripping leading zeroes from strings in javascript for conversions in order to provide a uniformly behaving method:  
43c43,45
< </code>
\ No newline at end of file
---
> </code>
> 
> 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]]
\ No newline at end of file