Validate number length when coercing String to double - #6179
Conversation
🧪 Code Coverage Report
|
cowtowncoder
changed the title
| // Number-length constraint (StreamReadConstraints.maxNumberLength) must be enforced | ||
| // when coercing a String to `double` the same way it already is for `float`. | ||
| public class DoubleFPLengthConstraintTest |
There was a problem hiding this comment.
Adding issue related-comments like
// [databind#6179] ... remaning description..... this is convential.
There was a problem hiding this comment.
Speaking of which, no issue open?
It would be great if you could open an issue @aysha-afrah26 👍
🧪 Code Coverage Report
|
Code Review ✅ ApprovedAdds validation of number length when coercing String to OptionsAuto-apply is off → Gitar will not commit updates to this branch. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source |
🧪 Code Coverage Report
|
4 participants
When a JSON string is coerced to a
double, the value goes throughStdDeserializer._parseDoublePrimitive, which hands the text straight to the double parser. Its sibling_parseFloatPrimitive, right above it, first checksNumberInput.looksLikeValidNumberand then callsstreamReadConstraints().validateFPLength()so the configuredmaxNumberLengthlimit applies before parsing, but the double variant skips both. The effect is thatfloat[]rejects an over-length numeric string whiledouble[],OptionalDouble, and the general String-to-double coercion accept it, so a length limit the user configures is not honored on those paths. I noticed it while comparing the two primitive helpers, since every integer-family helper in the same class already validates length the same way. The fix applies the same pre-validation to the double path so both behave alike. Added a test in thedeser/dospackage coveringdouble[], alongsidefloat[]which already enforces the limit.