将int（-2 ^ 31..2 ^ 31-1）超出范围的长整数转换为int会发生什么？

Question

I was running code in an attempt to figure out the behavior of Java when losing precision due to casting between the integral decimal numeric types, and I found an unexpected result:

long l2 = 999999999999999999L;   //outside of range -2147483648..2147483647 for int
int i3=(int)l2;    
System.out.println(l2); //999999999999999999, as expected.
System.out.println(i3); //I expected 2147483647, but got -1486618625

Can someone please explain how I'm getting a large negative int out of a large positive long? I would have expected the system to at least make a best effort casting attempt, returning the maximum positive integer (the closest valid int to the long which is too large to be stored in integer.) Instead, I'm getting a negative number which does not make sense to me.

Answer 1

The narrowing primitive conversion of a long to an int discards all but the lower order 32 bits of the original number, so you don't get Integer.MAX_VALUE .

The JLS, Section 5.1.3 , states:

A narrowing conversion of a signed integer to an integral type T simply discards all but the n lowest order bits, where n is the number of bits used to represent type T. In addition to a possible loss of information about the magnitude of the numeric value, this may cause the sign of the resulting value to differ from the sign of the input value.

This is in contrast to a primitive narrowing conversion from a floating-point type to an int , which may result in Integer.MAX_VALUE if the original value was too big.

double l2 = 999999999999999999.0;
System.out.println((int) l2);

This prints:

2147483647

Answer 2

Let's first take a look at the result number bits :

Now look at the bits representation of 999999999999999999 :

Notice that the first 32 bits is the same in both case.

Now considering the JLS, Section 5.1.3, as rgettman stated :

A narrowing conversion of a signed integer to an integral type T simply discards all but the n lowest order bits, where n is the number of bits used to represent type T. In addition to a possible loss of information about the magnitude of the numeric value, this may cause the sign of the resulting value to differ from the sign of the input value.

So you would only keep the 32 first bits (10100111011000111111111111111111) when doing the cast. Therefore, considering the highest bit of a signed integer represent the sign of the number you will have a negative(1)0100111011000111111111111111111

Which is equals to -1486618625 as decimal value.

Answer 3

A cast does not do any conversations nor does it care about the data. (or about truncating)

999999999999999999 in binary is 0000 1101 1110 0000 1011 0110 1011 0011 1010 0111 0110 0011 1111 1111 1111 1111 .

When casting this to an signed int, just the lower 32 bits will be used: 1010 0111 0110 0011 1111 1111 1111 1111 - Now, that number means (its an signed integer now due to casting):

• Leading 1 = negative number
• 010 0111 0110 0011 1111 1111 1111 1111 would be 660865023 in dec... not correct.
• Java uses the Two's complement, which means if you are only looking at the "number" of a negative number, you need to invert every bit and add 1 to get the actual numeric value:

so:

 010 0111 0110 0011 1111 1111 1111 1111 
 101 1000 1001 1100 0000 0000 0000 0000 + 1 
 101 1000 1001 1100 0000 0000 0000 0001 

101 1000 1001 1100 0000 0000 0000 0001 is 1486618625 - and it's negative: Voila, your -1486618625

Answer 4

The highest bit of a signed integer is the sign bit. So, if you overflow an operation into that bit, you will get a negative number. In this case you are doing it by casting.

= 1101 1110 0000 1011 0110 1011 0011 1010 0111 0110 0011 1111 1111 1111 1111

Truncated to (int):
                     1010 0111 0110 0011 1111 1111 1111 1111


Twos' compliment transform:

                     0101 1000 1001 1100 0000 0000 0000 0001 = 1486618625