flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Dove (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLEX-35283) parseInt Implementation
Date Mon, 20 Mar 2017 18:02:44 GMT

    [ https://issues.apache.org/jira/browse/FLEX-35283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15933198#comment-15933198

Greg Dove commented on FLEX-35283:

For swf, I actually checked quickly in Adobe Animate, not with Falcon, so perhaps it is different.
There seems to be no runtime typecheck and values are coerced when undefined or untyped, but
the compiler does check and give an error for other obvious mismatches
var radix:*="16"
trace(parseInt("99",radix)) //153
trace(parseInt("0x99",undefined)) //153
trace(parseInt("0x99",0)) //153


In any case, we don't need to do anything on the swf side, unless I misunderstood something.
For the zero vs. undefined, I wondered if GCC specified that because there is a different
optimization path triggered for that compared to using 0, Because this is simply js output
we can choose whatever makes more sense for GCC. I will try both and see if there is any noticeable
difference in the generated release code. If there is no difference I will use 0.

> parseInt Implementation
> -----------------------
>                 Key: FLEX-35283
>                 URL: https://issues.apache.org/jira/browse/FLEX-35283
>             Project: Apache Flex
>          Issue Type: Bug
>          Components: FalconJX
>    Affects Versions: Apache FalconJX 0.8.0
>            Reporter: Greg Dove
>            Assignee: Greg Dove
> parseInt does not correctly process hex strings without no second parameter
> parseInt("0x99")
> this should calculate as 153
> it is currently compiled to 
> parseInt("0x99",10)
> in js which evaluates to 0

This message was sent by Atlassian JIRA

View raw message