[jira] [Comment Edited] (GROOVY-7385) Invalid Integer & Long literals compile when they shouldn't

["Sean Gilligan (JIRA)" <ji...@apache.org>]

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

Sean Gilligan edited comment on GROOVY-7385 at 4/23/15 1:25 AM:
----------------------------------------------------------------

Good, point -- I read that in the Java Language Spec, but forgot about it in my last comment. What Java is doing makes sense -- when specifying numbers in hex, programmers are treating them as unsigned and would expect 0x8000_0000_0000_0000L to be negative. So yes, the checking needs to be different for Base 10 vs the other bases.

It looks like {{Numbers.java}} throws ``NumberFormatException`` when floating point literals are out of range. It would be friendly, I think, to not allow something like {{0.100000001f}} to compile (i.e. the user has explicitly specified precision greater than supported), but (my understanding of) [3.10.2. Floating-Point Literals|http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.10.2] says that this is allowed:

bq. A compile-time error does not occur if a non-zero floating-point literal has a small value that, on rounded conversion to its internal representation, becomes a non-zero denormalized number.

However a compile time error is required if a number rounds to zero:

bq. It is a compile-time error if a non-zero floating-point literal is too small, so that, on rounded conversion to its internal representation, it becomes a zero.

The nice thing about Groovy is that you can use {{BigDecimal}} literals just by removing the type suffix from the end. But it seems that anything with a type suffix that won't compile in Java should not compile in Groovy, as well.




was (Author: msgilligan):
Good, point -- I read that in the Java Language Spec, but forgot about that in my last comment. What Java is doing makes sense -- when specifying numbers in hex, programmers are treating them as unsigned and would expect 0x8000_0000_0000_0000L to be negative. So yes, the checking needs to be different for Base 10 vs the other bases.

It looks like {{Numbers.java}} throws ``NumberFormatException`` when floating point literals are out of range. It would be friendly, I think, to not allow something like {{0.100000001f}} to compile (i.e. the user has explicitly specified precision greater than supported), but (my understanding of) [3.10.2. Floating-Point Literals|http://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.10.2] says that this is allowed:

bq. A compile-time error does not occur if a non-zero floating-point literal has a small value that, on rounded conversion to its internal representation, becomes a non-zero denormalized number.

However a compile time error is required if a number rounds to zero:

bq. It is a compile-time error if a non-zero floating-point literal is too small, so that, on rounded conversion to its internal representation, it becomes a zero.

The nice thing about Groovy is that you can use {{BigDecimal}} literals just by removing the type suffix from the end. But it seems that anything with a type suffix that won't compile in Java should not compile in Groovy, as well.



> Invalid Integer & Long literals compile when they shouldn't
> -----------------------------------------------------------
>
>                 Key: GROOVY-7385
>                 URL: https://issues.apache.org/jira/browse/GROOVY-7385
>             Project: Groovy
>          Issue Type: Bug
>          Components: syntax
>    Affects Versions: 2.4.3
>         Environment: Mac OS X
>            Reporter: Sean Gilligan
>            Assignee: Jochen Theodorou
>
> 2147483648I should be an invalid Integer literal.
> 9223372036854775808L should be an invalid Long literal.
> Both currently compile (and produce an unexpected value -- well, it would be the expected value in 2's complement math)
> I created some unit tests to show the problem -- not sure if I put them in the right place, but they do fail as I expect them to.
> The Github PR is here: 
> https://github.com/groovy/groovy-core/pull/657
> The build output is here:
> http://ci.groovy-lang.org/viewLog.html?buildId=16410&buildTypeId=Groovy_Jdk7Build



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)