ParseByteUnits() is the only parsing function in strencodings.cpp lacking a fuzz test. Add a test case to check the function against arbitrary strings and randomized default_multiplier.
ParseByteUnits()
#34017
ParseByteUnits() is the only parsing function in strencodings.cpp lacking a fuzz test. Add a test case to check the function against arbitrary strings and randomized default_multiplier.
`ParseByteUnits()` is the only parsing function in `strencodings.cpp`
lacking a fuzz test. Add a test case to check the function against
arbitrary strings and randomized default_multiplier's.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34017.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | dergoegge, marcofleon, maflcko |
If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.
utACK 57b888ce0ebdeb34d866fd1511052fd740cc5ab8
Thank you for your interest in contributing to our fuzzing efforts! This looks fine to me.
ParseByteUnits is not publicly exposed, i.e. it doesn’t handle untrusted inputs, and I would not consider adding fuzz tests for this type of function as a priority. As the in-repo fuzz tests are pretty saturated, it can be hard to spot valuable areas to improve (especially if you are new to the code base). A good path for making valuable contributions is to review other fuzzing PRs (e.g. #31533 or #33300).
crACK 57b888ce0ebdeb34d866fd1511052fd740cc5ab8
Ran it for a bit as a sanity check, seems fine.
ParseByteUnitsis not publicly exposed, i.e. it doesn’t handle untrusted inputs, and I would not consider adding fuzz tests for this type of function as a priority.
Makes perfect sense. But I wonder why fuzz tests for these internal utilities (like ToUpper(), ToLower(), etc.) were introduced in the first place? Is it being thorough just for the sake for being thorough?
As the in-repo fuzz tests are pretty saturated, it can be hard to spot valuable areas to improve (especially if you are new to the code base). A good path for making valuable contributions is to review other fuzzing PRs (e.g. #31533 or #33300).
Will do!