flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Harui (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLEX-35283) parseInt Implementation
Date Tue, 21 Mar 2017 17:43:41 GMT

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

Alex Harui commented on FLEX-35283:
-----------------------------------

Wow!  That's really thorough research!  Thanks for doing it.

Using 'undefined' or 'void 0' is ok with me, but it makes me wonder why Google bothered to
make the second parameter required.  I would think the second argument would be 'undefined'
if it was optional and left out of the code.

As long as the main goal of having AS results match JS results for all combinations of one
or two parameters into parseint, and the output overhead and compiler overhead is small, I
think we have arrived at the right answer.

> 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)

Mime
View raw message