sahvx655-wq opened a new pull request, #406:
URL: https://github.com/apache/commons-validator/pull/406
Following up on the earlier range-check work I checked what validate()
actually hands back for high-precision input, and both validators drop digits.
BigDecimalValidator.validate("0.12345678901234567890") returns
0.12345678901234568, and BigIntegerValidator on an integer past the long range
(92233720368547758077) returns 92233720368547760000. The parse runs through the
inherited NumberFormat, whose default DecimalFormat returns a Double for any
fractional value or any integer outside long range, so the value is already
rounded to roughly 17 significant figures before it is wrapped in a BigDecimal
or BigInteger. For a pair of classes whose whole purpose is exact conversion
that is a real correctness problem, and it is silent: no exception, just a
different value than the caller supplied.
Overriding getFormat in each validator to put the DecimalFormat into
setParseBigDecimal(true) makes parseObject return a BigDecimal up front, so the
exact value reaches the conversion step. It belongs at the format layer because
that is where the lossy Double is created, and nothing downstream can recover
digits that parsing has already discarded. The two validators are kept in step,
which an existing test already pins to the same magnitude, and one fixture that
encoded the rounded result has been updated to the exact value. New regression
tests cover a high-precision decimal and an integer scaled up from
Long.MAX_VALUE.
--
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]
