RFR: 8314258: checked_cast doesn't properly check some cases

[Kim Barrett]

On Thu, 5 Feb 2026 00:03:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this addition of the `integer_cast` utility.
> 
> Details in first comment, to avoid email spamming from automatic messages.
> 
> Testing: mach5 tier1-5 with `checked_cast` for integral types changed to call
> the new `integer_cast`.  Addition of `integer_cast` includes gtests.

Details:

`checked_cast` was added by JDK-8255544 to permit silencing of certain
compiler warnings (such as from gcc's `-Wconversion`) for narrowing
conversions when the value is "known" to be safely convertible. It provides
debug-only runtime verification that the "known safe" conversion preserves the
value while changing the type.

There has been a recent effort to apply `checked_cast` to eliminate
`-Wconversion` warnings, with the eventual goal of turning on such warnings by
default - see JDK-8135181.

`checked_cast` checks that the value is unchanged by a round-trip conversion,
and has no restrictions on the arguments. There are several problems with
this.

1. There are some cases where conversion of an integral value to a different
integral type may pass the check, even though the value isn't in the range of
the destination type. This doesn't match the behavior of `-Wconversion`.

2. Floating point to integral conversions are often intended to discard the
fractional part. But that won't pass the round-trip conversion test, making
`checked_cast` mostly useless for such conversions.

3. Integral to floating point conversions are often intended to be
indifferent to loss of precision. But again, that won't pass the round-trip
conversion test, making `checked_cast` mostly useless for such conversions.

4. The round-trip check isn't always safe.  For example, a narrowing integer
to enum conversion is undefined behavior.  (There was one `checked_cast` of
this kind, which was removed by JDK-8374712.)

This change proposes to add `integer_cast` to support integral to integral
conversions. It ensures (in debugging builds) that the value being converted
is in the range of the destination type. Note that this means it can also be
used to suppress `-Wsign-conversion` warnings (which are not included in gcc's
`-Wconversion` when compiling C++), which we might explore enabling in the
future.

`integer_cast` also verifies a runtime check is needed, producing a
compile-time error if not. Unnecessary casts make the code harder to
understand. This will alert a developer that a change is rendering an
`integer_cast` unnecessary, so it can be removed. This compile-time check can
be suppressed on a per-call basis, as there are cases where a runtime check
might only sometimes be needed. (There are currently about 1/2 dozen
unnecessary checked_casts, and a dozen that are conditionally tautological.)

The intent is that appropriate uses of `checked_cast` will be converted to use
`integer_cast` instead, and `integer_cast` will be used for future work where
appropriate. This will be used in conjunction with a future gcc warning
configuration of `-Wconversion -Wno-float-conversion`. If/when we later want
to enable `Wfloat-conversion`, we can add new functions tailored for the
various use cases. (I expect that `checked_cast` will become vestigal and
eventually removed.) This conversion will be done in followup issues.

The new `integer_cast` also supports supports enum to integral conversions,
mostly for compatibility with old code that uses class-scoped enums instead of
class-scoped static const integral members, to work around ancient broken
compilers. We still have a lot of such code.

An alternative to having a new name would be to respecify and reimplement
`checked_cast`.  `integer_cast` seems like a better name for this function.
The downside is the naming churn. 

In addition to `integer_cast`, this change also provides a couple of related
utilities: `is_always_integer_convertible` and `is_integer_convertible`.
These are used in the implementation of `integer_cast`, but are also available
to code that wants to check whether a conversion is safe and do something
other than just assert when not.

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

PR Comment: https://git.openjdk.org/jdk/pull/29582#issuecomment-3850345333