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