On Wed, 17 Jun 2026 19:08:57 GMT, Ferenc Rakoczi <[email protected]> wrote:

>> Yes, the definition of Java class `IntegerPolynomial` does limit the 
>> possible subclasses. However, as I mentioned in my earlier comment, that 
>> list includes `IntegerPolynomialModBinP`
>> 
>> 
>> public abstract sealed class IntegerPolynomial implements IntegerFieldModuloP
>>     permits IntegerPolynomial1305, IntegerPolynomial25519,
>>             IntegerPolynomial448, IntegerPolynomialP256,
>>             MontgomeryIntegerPolynomialP256, IntegerPolynomialP384,
>>             IntegerPolynomialP521, IntegerPolynomialModBinP, P256OrderField,
>>             P384OrderField, P521OrderField, Curve25519OrderField,
>>             Curve448OrderField {
>> 
>> 
>> This specific subclass employs a limb count specified by a caller in the 
>> constructor
>> 
>> 
>> public sealed class IntegerPolynomialModBinP extends IntegerPolynomial {
>>     ...
>>     public IntegerPolynomialModBinP(int bitsPerLimb,
>>                                     int numLimbs,
>>                                     int power,
>>                                     BigInteger subtrahend) {
>>         super(bitsPerLimb, numLimbs, 1,
>>             BigInteger.valueOf(2).pow(power).subtract(subtrahend));
>> 
>> 
>> So, for this class it looks as if a user could specify numLimbs == 0 when 
>> creating an `IntegerPolynomialModBinP` and that same count will be passed on 
>> up to `IntegerPolynomial`.
>> 
>> Now, that doesn't guarantee that any subsequent call to 
>> `IntegerPolynomial::mult` will end up being passed a zero length array but 
>> I'd like to be reassured why this won't happen.
>
> 0 as number of limbs doesn't make sense as no number can be represented that 
> way. I think the IntegerPolynomialModBinP class was created for testing 
> purposes mainly and only the two inner classes should subclass it, i.e. the 
> constructor should rather be private and in that case the 0 number of limbs 
> would not be a concern. @ascarpino, do you remember what this class was made 
> for and whether it is obsolete now?

Perhaps the `Curve25519OrderField` and `Curve448OrderField` can be refactored 
away from `IntegerPolynomialModBinP`, but I would not suggest that for this PR.

I'm ok with changing the constructor to be private, but it's not accessible 
from the public API, so it's not a necessary change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/30941#discussion_r3432048761

Reply via email to