sahvx655-wq opened a new pull request, #419:
URL: https://github.com/apache/commons-validator/pull/419
**Float bound read at the wrong magnitude in the number range checks**
While extending the exact-bound range checks to a `Float` limit I found
`BigIntegerValidator.getInstance().maxValue(new
BigInteger("100000000000000000001"), 1e20f)` returning false, even though the
float `1e20f` actually holds 100000002004087734272 and the value sits below it.
The `Number` range overloads convert both operands through
`AbstractNumberValidator.toBigDecimal` before comparing, and that helper
branches on `Long`, `Double`, `BigDecimal` and `BigInteger` but has no `Float`
case, so a `Float` drops to the final `new BigDecimal(value.toString())`.
`Float.toString` emits only the digits needed to round-trip the value, so the
bound is rebuilt from "1.0E20" and compared as 10^20 rather than its real
magnitude, and anything between the two is mis-ranged.
Root cause is the missing branch, so I widened a `Float` through
`doubleValue()` and used `BigDecimal.valueOf`, mirroring the neighbouring
`Double` branch, and the operand is now compared at the value it truly holds.
If left as is a value near a float limit is silently admitted or rejected
across `BigIntegerValidator`, `BigDecimalValidator` and `DoubleValidator`, and
`toBigInteger` carries the same skew since it routes through `toBigDecimal`.
The regression test in `BigIntegerValidatorTest` derives its fixture from the
float itself so it does not lean on a hand-written constant.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
