sahvx655-wq commented on PR #387: URL: https://github.com/apache/commons-validator/pull/387#issuecomment-4639602999
I went back through the rest of GenericTypeValidator after this one. Short answer is no, formatLong was the only one with the gap. formatByte, formatShort and formatInt all range-check with num.doubleValue() the same way, but their bounds (±127, ±32767, ±2^31-1) sit well under 2^53, so they're exactly representable as doubles and the comparison is exact. Anything too large to be a long comes back from NumberFormat as a Double, and it's still larger than the int/short/byte maximum, so it gets rejected rather than clamped. formatDouble and formatFloat compare against Double.MAX_VALUE and Float.MAX_VALUE, and those constants are themselves exact as doubles, so nothing above the type maximum slips through. The float path still narrows in-range values with the usual precision loss, but that's the documented behaviour, not an out-of-range value being accepted and silently changed. The long case was the odd one out precisely because Long.MAX_VALUE (2^63-1) is the single bound that isn't representable as a double and rounds up to 2^63, which is what opened the hole. So I don't think there's a follow-up needed on the others. -- 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]
