sahvx655-wq opened a new pull request, #394: URL: https://github.com/apache/commons-validator/pull/394
BigIntegerValidator.validate runs the input through NumberFormat, which returns a Long while the number fits in a long and switches to a Double once it overflows. processParsedValue then converts via longValue(), and on a Double that saturates at Long.MAX_VALUE, so "99999999999999999999999999" comes back as 9223372036854775807 with no exception or warning to flag it. I caught this lining the integer validators up against each other: BigDecimalValidator routes the same parsed Double through its string form and keeps the magnitude, while BigIntegerValidator throws it away. Sending the non-Long branch through the parsed value's string form mirrors what BigDecimalValidator already does, so the two stay consistent on oversized input. Keeping the conversion inside processParsedValue covers every validate and isValid entry point without touching the shared parsing code. Left alone the behaviour is a quiet correctness hole: folding every large value onto one fixed number lets a later maxValue or range check pass for inputs the real number should fail. -- 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]
