RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors [v3]

Raffaello Giulietti rgiulietti at openjdk.org
Fri Nov 3 19:17:04 UTC 2023


On Fri, 3 Nov 2023 09:01:48 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 344:
>> 
>>> 342:      * @param  len the number of bytes to use.
>>> 343:      * @throws NumberFormatException {@code val} is zero bytes long,
>>> 344:      *         or {@code len} is zero.
>> 
>> I would be concerned about the compatibility impact on existing applications.
>> Though (very) uncommon, an existing application be using a non-zero length array and a len of zero to represent zero.
>> With this change it will throw an unexpected exception.
>
> A zero `len` is meant to indicate an empty range, whether the `val` array is empty or not.
> So, from a logical perspective, both cases `val.length == 0` or `len == 0` should either both throw, or both should return `BigInteger` 0.
> I choose the former, but the latter is a consistent choice as well.
> 
> What I find unpleasant is the current behavior: it throws on `val.length == 0` (even if `len == 0`), but curiously returns 0 when it is non-zero and `len == 0`. I find this rather inconsistent.

The `len == 0` -> 0 behavior has been recovered.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16449#discussion_r1382113596


More information about the core-libs-dev mailing list