On Tue, 26 Nov 2024 17:13:04 GMT, fabioromano1 <d...@openjdk.org> wrote:
>>> OK. But for the sake of completeness, I would add at least one test case >>> for an overflowing `workingScale`. >> >> I'm afraid it's not possible to produce such a test case, with the current >> implementation of `BigInteger`. >> Indeed, `workingScale` is defined by `workingScale = this.scale - >> normScale`, and `normScale` by: >> >> long ns = minWorkingPrec - this.precision() + this.scale; >> long normScale = ns + (ns & 1L); >> >> Therefore `workingScale == this.precision() - minWorkingPrec - (ns & 1L)`, >> so to overflow `workingScale` it is necessary to maximize >> `this.precision()`, thus`this.intVal` must have at least `Integer.MAX_VALUE >> + 1` digits, but `BigInteger.TEN.pow(Integer.MAX_VALUE)` surely exceeds the >> supported range for `BigInteger`s... > > Actually, this proves also that `workingScale` should never overflow, as > `this.precision()` is also an `int`, so it cannot have a value larger than > `Integer.MAX_VALUE`. I don't get your point. Here's an example: BigDecimal.ONE.sqrt(new MathContext(2_000_000_000, RoundingMode.UP)) | Exception java.lang.ArithmeticException: Overflow | at BigDecimal.sqrt (BigDecimal.java:2226) | at (#4:1) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1858957065
