RFR: 8314258: checked_cast doesn't properly check some cases [v2]

[Kim Barrett]

On Thu, 5 Feb 2026 11:53:18 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more testing
>
> Thank you Kim for this great work.
> Couple of questions:
> 
> To test some corner cases I used the templates in the following test:
> ```C++
> TEST(TestIntegerCast, additional_tests) {
>   // int32_t a = integer_cast<int32_t>(-1); // compile error
>   // int32_t b = integer_cast<int32_t>((int32_t)-1); // compile error
>   // int32_t c = integer_cast<int32_t>(1 << 31); // compile error
>   EXPECT_TRUE(is_integer_convertible<int32_t>(-1));
>   EXPECT_FALSE(is_integer_convertible<int32_t>(0xFFFFFFFF));
>   EXPECT_FALSE(is_integer_convertible<int32_t>(0x8000000000000000));
>   EXPECT_TRUE(is_integer_convertible<int32_t>(1 << 31));
>   EXPECT_FALSE(is_integer_convertible<int32_t>(1L << 63));
> 
>   EXPECT_TRUE(is_integer_convertible<int32_t>((int32_t)-1));
>   EXPECT_TRUE(is_integer_convertible<int32_t>((int32_t)0xFFFFFFFF));
>   EXPECT_TRUE(is_integer_convertible<int32_t>((int32_t)0x8000000000000000));
>   EXPECT_TRUE(is_integer_convertible<int32_t>((int32_t)(1 << 31)));
> }
> 
> I expected that all tests to be `EXPECT_TRUE` but they had to be the opposite to let the Test pass. How can we describe this?
> 
> Could we have such a unit test that shows how to _correctly_ use the templates and some comments on why some use-cases are wrong?
> How it should be interpreted that even when `is_integer_convertible(x)` returns `true` but `integer_cast(x)` fails in compilation?

@afshin-zafari 
> I expected that all tests to be EXPECT_TRUE but they had to be the opposite to
> let the Test pass. How can we describe this?

I don't know what you think is surprising with those results?  For example:

EXPECT_FALSE(is_integer_convertible<int32_t(0xFFFFFFFF));

is correct.  That *positive* value cannot be represented in an int32_t.
How is that behavior not clear from the description?


> How it should be interpreted that even when `is_integer_convertible(x)` returns
> true but `integer_cast(x)` fails in compilation?

The rationale for the `integer_cast` compilation failures for tautological
casts is in the function's description. How is that not clear?

I waffled about whether `is_integer_convertible` should similarly fail to
compile tautological cases. I could be convinced that it should. The rationale
is that we might use a test to protect code, with fall-back code for the
out-of-range case, and the (never executed) fall-back source code could be
eliminated when tautological.  The assumption here is that the protected code
would use an *implicit* conversion, and the compiler would (eventually, when
we have the warning turned on) complain if that conversion is potentially
narrowing.  So perhaps the behavior should be as-is for now, and changed once
we have the compiler warnings in place.

> src/hotspot/share/utilities/integerCast.hpp line 39:
> 
>> 37: // for the To Type.  From and To must be integral types.  This is used by
>> 38: // integer_cast to test for tautological conversions.
>> 39: template<typename From, typename To,
> 
> The order of From and To parameters is not consistent with the rest of the other templates.

The parameter order here is consistent with the `std::is_convertible<>` and
`std::is_base_of<>` traits. It "reads" similarly, i.e. it returns true if
`From` is convertible to `To`. The order of the template parameters for the
others is required in order to allow the `To` parameter to be explicit
(necessary) while the `From` parameter is (always in actual usage) deduced.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29582#issuecomment-3867900439
PR Review Comment: https://git.openjdk.org/jdk/pull/29582#discussion_r2779663273