Repository navigation
Conversation
Contributor
|
There should probably be a trac ticket for this PR. Please create it, or ask us to create it. Then the PR title should be updated. |
Contributor
Author
|
hey can anyone create trac ticket for this pr, thanks. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CheckIOImpl::checkFormatString converts the digits collected for a field width or a POSIX parameter position with strToInt, which throws when the digits are empty (
%$d), start with a zero (%01$d, which glibc accepts) or do not fit in an int (%99999999999$d,scanf("%99999999999s", buf)with a known array), so one such format string makes CppCheck::checkFile bail out with an internalError and drop every other diagnostic for that file. Replaced the conversion with a small helper that parses the digits without throwing and clamps anything above INT_MAX, and a$with no digits in front is no longer taken as a parameter position; widths and positions that fit in an int behave exactly as before, while an oversized one is now reported through the existing invalidScanfFormatWidth and wrongPrintfScanfParameterPositionError messages, with 2147483647 shown for the clamped value. Verified with an ASan/UBSan build: the new asserts in TestIO::testScanf4 and testPosixPrintfScanfParameterPosition throw on main and pass with the fix, the full testrunner is green, and the selfcheck options report nothing for lib/checkio.cpp. I do not have Trac access, so could you create a ticket for this? I will update the title to reference it once there is a number.