RFR: 8346914: UB issue in scalbnA

[David Holmes]

On Tue, 10 Jun 2025 06:30:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> FYI, as an alternative, there is a Java-only implementation of scalb (and supporting functionality) in java.lang.Math that could be ported to C as another way to avoid this issue.
>
> `java.lang.Math.scalb()` doesn't seem useful here. It just transforms the
> scale factor into a double power of 2 and then multiplies. It's not clear that
> would result in exactly the same result for all arguments as this. And this is
> (mostly) avoiding doing a double multiply for (perceived) performance reasons.
> (For all I know, the complexity here could swamp the cost of a double
> multiply.) Being certain of keeping the same results (on edge cases) is the
> only reason to stay with this (but fixed to remove UB), rather than just
> switching to using the C/C++ library `scalbn`. (And I don't know that
> there *is* any potential difference between `scalbnA` and `scalbn` that would
> actually matter. That would require more analysis than I've had time to do.)

I don't understand your comment here Kim but I am certainly not going to mess with the existing algorithm. All I am trying to do is avoid the case where a direct `k+n` would wrap to a negative value. I have no idea what the possible range of values for `n` might be or whether we have to account for underflow as well, but that seems a distinct issue to dealing with the potential UB overflow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25656#discussion_r2151509071