[
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
trace(int(undefined))//0
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
(v6.3.15#6346)
