sahvx655-wq opened a new pull request, #387: URL: https://github.com/apache/commons-validator/pull/387
While going over the numeric format helpers I noticed formatLong(String, Locale) range-checks the parsed number with num.doubleValue() against Long.MIN_VALUE and Long.MAX_VALUE. Long.MAX_VALUE is not exactly representable as a double, so it is promoted to 2^63 in that comparison. Parsing "9223372036854775808" (Long.MAX_VALUE + 1), which NumberFormat returns as a Double that rounds to 2^63, then satisfies the upper bound and is accepted; longValue() afterwards clamps it back to Long.MAX_VALUE, so the helper reports a value the caller never entered. "-9223372036854775809" behaves the same way at the lower bound. The root cause is using a lossy double comparison to decide whether an integral value fits in a long. The fix accepts the result only when NumberFormat hands back a Long, which it does exactly when the value fits in a long; anything out of range comes back as a Double and is now rejected. This matches what routines.LongValidator already does and keeps the bounds decision inside the conversion routine instead of leaving callers to second-guess a silently clamped result. Left unfixed this lets out-of-range input pass validation and corrupt the converted value. The other format* methods are untouched because their int/short/byte bounds are exact as doubles, so the same rounding gap does not arise. -- 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]
