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