[Nussu06]

polyspace::Parser::parseRange reads the +N range of a Polyspace comment with std::stoi and only catches std::invalid_argument, so a source file containing /* polyspace +99999999999 MISRA2012:8.4 */ throws std::out_of_range past CppCheck::checkFile and aborts cppcheck when it runs with --inline-suppr and the misra addon or a premium MISRA/CERT option. A range that does fit, such as +2147483647 on line 2, instead overflows line + rangeValue in Parser::parse (UBSan: signed integer overflow) and leaves a negative lineEnd. An out-of-range number is now treated like any other invalid range, and lineEnd is clamped to INT_MAX instead of wrapping, so valid ranges are unchanged. The new asserts in polyspaceParseRange and polyspaceRange fail on main, and the full testrunner passes in an ASan/UBSan build. There is no Trac ticket for this yet; I can update the title once one exists.

[dmcppcheck]

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.

[Nussu06]

I don't have Trac access, so could you create the ticket for this one? Once there's a number I'll update the title to "Fix #NNNN (...)" like the others.

For the ticket: with --inline-suppr and the misra addon (or a premium MISRA/CERT/AUTOSAR option), a Polyspace annotation whose +N range doesn't fit in an int crashes cppcheck, because polyspace::Parser::parseRange only catches std::invalid_argument from std::stoi:

printf 'int x;\n/* polyspace +99999999999 MISRA2012:8.4 */\nint y;\n' > b.c
cppcheck --inline-suppr --addon=misra -q b.c
# terminating due to uncaught exception of type std::out_of_range: stoi: out of range

A range that does fit, e.g. +2147483647 on line 2, overflows line + rangeValue in Parser::parse instead (UBSan: signed integer overflow) and gives a negative lineEnd.

[danmar]

I have created https://trac.cppcheck.net/ticket/15181

[danmar]

ping? there is a small formatting thing. and resolve the merge conflict..

[Nussu06]

Sorry for the delay. Rebased onto main (the conflict was just the include list, since main dropped <functional>), and put the two catch clauses on one line the way uncrustify wants them. Title now references #15181. TestSuppressions passes locally.

[dmcppcheck]

AI review

I found no new problems. When the +N range is too large for an int, parseRange now catches std::out_of_range and returns 0, so the comment is treated like any other invalid range. When the range fits in an int but line + N would overflow, lineEnd is capped at INT_MAX before the addition happens. Block matching only compares line numbers against lineEnd (lib/suppressions.cpp:482 and :732), so capping it at INT_MAX does no harm. The new tests cover both cases.

Earlier comments

#	Comment	By	Where	Status
1	PR should have a trac ticket and the title should reference it	@dmcppcheck	general	✅ Fixed
2	Small formatting fix needed and merge conflict to resolve	@danmar	general	✅ Fixed

Testing

• Built cppcheck and testrunner in /work/pr; the build succeeded.
• ./testrunner TestSuppressions passed with 0 failures.
• I ran two inputs through the PR's cppcheck with --inline-suppr --addon=misra. Both exited with code 0 and printed nothing, so there was no crash or abort:
  • printf 'int x;\n/* polyspace +99999999999 MISRA2012:8.4 */\nint y;\n' > b.c, the case from the description.
  • The same file with +2147483647.
• I couldn't run the premium options: this build rejects --premium=misra-c-2012 with "unrecognized command line option".
• I didn't build base/ and didn't run a sanitizer build, so I haven't seen the crash or the UBSan overflow on main for myself.

---

Automated review of 5256aa3 by Claude. The pull request was built and tested locally.

[danmar]

I prefer catch statements on separate lines.

[Nussu06]

Done, each catch is on its own line now.

[danmar]

I don't remember.. is it guaranteed that line is positive?
I assume it should be but would it make sense to check that it is or is that just redundant?

[Nussu06]

Not guaranteed, so the check isn't redundant. simplecpp only warns on #line 0 or #line values above 2147483647 and keeps the value, and Location::line is unsigned, so #line 4294967295 reaches parse() as -1. With the previous expression INT_MAX - line then overflowed itself (UBSan: 2147483647 - -1). Rather than special-casing the sign I now do the addition in long long and clamp to INT_MAX, which is safe for any int line, and added a polyspaceRange case with line -1.