AI review of 2026-10-07_14-28-56-8e9a9d71a898-results.txt PR: #8881 https://github.com/cppcheck-opensource/cppcheck/pull/8881 Tested: 8e9a9d71a898566b57f6ddd98d20655131b156ec Merge base: 2c6098ded748110d507ae23d6a2ea2b56da130bb Reviewed: 2026-10-09 11:20:43 UTC Model: claude-opus-5-5 (effort high) Results: 12 reviewed of 12 in the report Verdicts: 8 improvement, 2 neutral, 2 regression Tokens: 24908 input, 27775 cache read, 2525 cache write, 7334 output The verdicts are written by AI and can be wrong. ---- 1 / 12 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/freecad/freecad_1.1.3+dfsg.orig.tar.xz Result: main src/Gui/OnlineDocumentation.cpp:108:16: error: Out of bounds access in expression 'res[i]' because 'res' is empty. [containerOutOfBounds] src/Gui/OnlineDocumentation.cpp:97:24: note: Assuming condition is false src/Gui/OnlineDocumentation.cpp:108:16: note: Access out of bounds Explanation: In the else branch, `res` is a freshly constructed QByteArray. `reserve()` does not change its size, so `res[i]` writes past the end every time that branch runs (with Qt6, `operator[]` returns `char&` and requires `i < size()`). The access sits inside the else block itself, so it is not conditionally out of bounds: whenever it executes, it is out of bounds. The condition note only reflects which branch is taken. Downgrading this from error to warning because the value is marked 'conditional' understates a definite bug. It is the same kind of loss the PR itself records with a TODO for the loop case. ---- 2 / 12 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/freecad/freecad_1.1.3+dfsg.orig.tar.xz Result: your src/Gui/OnlineDocumentation.cpp:108:16: warning: Out of bounds access in expression 'res[i]' because 'res' is empty. [containerOutOfBounds] src/Gui/OnlineDocumentation.cpp:97:24: note: Assuming condition is false src/Gui/OnlineDocumentation.cpp:108:16: note: Access out of bounds Explanation: In the else branch, `res` is a freshly declared, empty QByteArray. `reserve()` does not change its size, so `res[i]` indexes past the end on every execution of that branch. With Qt6's `char&` operator[] this is undefined behavior. The emptiness does not depend on the `writer.canWrite()` condition; the access is simply located inside the else block, and there it is always out of bounds. The PR downgrades this report from error to warning only because the value is flagged as conditional. That understates a definite bug, so the message is less accurate. ---- 3 / 12 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libn/libncl/libncl_2.1.21+git20210811.b1213a7.orig.tar.xz Result: main libncl-2.1.21+git20210811.b1213a7/ncl/nxsreader.cpp:222:26: error: Out of bounds access in expression 'byPriority.rbegin()' because 'byPriority' is empty. [containerOutOfBounds] libncl-2.1.21+git20210811.b1213a7/ncl/nxsreader.cpp:215:64: note: Assuming condition is false libncl-2.1.21+git20210811.b1213a7/ncl/nxsreader.cpp:222:26: note: Access out of bounds Explanation: This warning is a false positive both before and after the PR. `found` is checked with `found.empty()` and the function returns early if it is empty. So the loop runs at least once and `byPriority` always has at least one entry before `rbegin()`. There is even an assert saying so. The PR does not remove the false positive, but it lowers it from error to warning. That is the intended effect of the PR, because the empty-container value only comes from assuming the loop condition is false, i.e. a conditional value. A false positive reported as a lower-severity warning matches its uncertain basis better and does less harm, so the change is a slight improvement. ---- 4 / 12 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libn/libncl/libncl_2.1.21+git20210811.b1213a7.orig.tar.xz Result: your libncl-2.1.21+git20210811.b1213a7/ncl/nxsreader.cpp:222:26: warning: Out of bounds access in expression 'byPriority.rbegin()' because 'byPriority' is empty. [containerOutOfBounds] libncl-2.1.21+git20210811.b1213a7/ncl/nxsreader.cpp:215:64: note: Assuming condition is false libncl-2.1.21+git20210811.b1213a7/ncl/nxsreader.cpp:222:26: note: Access out of bounds Explanation: This is a false positive. `found` is checked non-empty at line 212, so the loop over `found` runs at least once and inserts into `byPriority`. The map can never be empty at line 222, and the code even asserts it. Cppcheck only reaches the empty state by assuming the loop condition is false on the first iteration, which is a conditional value. The PR does not remove the false positive, but it now reports this conditional finding as a warning instead of an error. A wrong report at a lower, more fitting severity is a small gain for users. ---- 5 / 12 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xapian-omega/xapian-omega_2.1.0.orig.tar.xz Result: main xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:51:29: error: Out of bounds access in expression 'str_docids[j]' [containerOutOfBounds] xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:50:26: note: Assuming that condition 'j<=str_docids.length()' is not redundant xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:51:29: note: Access out of bounds Explanation: The loop runs `j <= str_docids.length()` and reads `str_docids[j]`, where `str_docids` is a `const std::string&`. Reading `s[s.size()]` on a std::string is well-defined: it returns the terminating '\0', which the code explicitly checks for. So the containerOutOfBounds report is a false positive under both main and the PR. The PR only changes its severity from error to warning, because the index value comes from an assumed condition. The false positive is still reported, so it is neither fixed nor made worse in substance. The lower severity is at most a marginal cosmetic change. ---- 6 / 12 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xapian-omega/xapian-omega_2.1.0.orig.tar.xz Result: main xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:70:29: error: Out of bounds access in expression 'str_clicks[j]' [containerOutOfBounds] xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:69:26: note: Assuming that condition 'j<=str_clicks.length()' is not redundant xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:70:29: note: Access out of bounds Explanation: The loop reads `str_clicks[j]` for `j == str_clicks.length()` on a `const std::string&`. Since C++11, `operator[]` at `size()` is defined and returns the terminating `'\0'`. The code relies on this to flush the last click value, so the containerOutOfBounds report is a false positive. The PR does not remove it, but downgrades it from error to warning. The finding rests only on a 'condition is not redundant' assumption, so warning is the more fitting severity. That makes a wrong report less harmful. ---- 7 / 12 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xapian-omega/xapian-omega_2.1.0.orig.tar.xz Result: main xapian-omega-2.1.0/runfilter.cc:488:38: error: Out of bounds access in expression 'cmdline[0]' because 'cmdline' is empty. [containerOutOfBounds] xapian-omega-2.1.0/runfilter.cc:483:24: note: Assuming condition is false xapian-omega-2.1.0/runfilter.cc:488:38: note: Access out of bounds Explanation: Line 488 takes `&cmdline[0]`. `cmdline` is empty only if the loop over `cmd` never runs, which is why the trace says "Assuming condition is false". Even then, `std::string::operator[](size())` is well defined since C++11 and returns a reference to the terminating null character. So this report is a false positive either way. The PR does not remove it but downgrades it from error to warning, because the empty state depends on an assumed condition. A false positive at lower severity, with a severity that better fits a conditional finding, is a modest improvement. ---- 8 / 12 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xapian-omega/xapian-omega_2.1.0.orig.tar.xz Result: your xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:51:29: warning: Out of bounds access in expression 'str_docids[j]' [containerOutOfBounds] xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:50:26: note: Assuming that condition 'j<=str_docids.length()' is not redundant xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:51:29: note: Access out of bounds Explanation: The loop reads `str_docids[j]` for j up to and including `length()`. For a const `std::string`, `operator[](size())` is well-defined since C++11: it returns a reference to the terminating '\0'. The code relies on this to detect the end of the string, so the containerOutOfBounds report is a false positive in both main and the PR. The PR only changes its severity from error to warning. Lowering the severity of a false positive is slightly less harmful, but the bogus report is still there, so the practical effect for users is negligible. ---- 9 / 12 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xapian-omega/xapian-omega_2.1.0.orig.tar.xz Result: your xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:70:29: warning: Out of bounds access in expression 'str_clicks[j]' [containerOutOfBounds] xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:69:26: note: Assuming that condition 'j<=str_clicks.length()' is not redundant xapian-omega-2.1.0/clickmodel/simplifieddbn.cc:70:29: note: Access out of bounds Explanation: The loop runs `j` up to `str_clicks.length()` and reads `str_clicks[j]`. For `std::string`, `operator[](size())` is well-defined since C++11 and returns `'\0'`. The code deliberately relies on that terminator, so the report is a false positive either way. The PR only lowers its severity from error to warning, because the index value comes from an 'assuming condition is not redundant' conditional value. A false positive reported as a warning instead of an error is less harmful. Warning severity also better fits a conditional finding, so this is a mild improvement, although the false positive itself remains. ---- 10 / 12 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xapian-omega/xapian-omega_2.1.0.orig.tar.xz Result: your xapian-omega-2.1.0/runfilter.cc:488:38: warning: Out of bounds access in expression 'cmdline[0]' because 'cmdline' is empty. [containerOutOfBounds] xapian-omega-2.1.0/runfilter.cc:483:24: note: Assuming condition is false xapian-omega-2.1.0/runfilter.cc:488:38: note: Access out of bounds Explanation: The empty-string case only occurs if the loop at line 483 never runs, i.e. `cmd[0]` is null. That makes the out-of-bounds value conditional, which is the case the PR now reports as a warning instead of an error. In addition, `&cmdline[0]` on an empty std::string is well-defined since C++11: index size() returns a reference to the null terminator. So the report is really a false positive. Downgrading it from error to warning makes it less harmful and more consistent with the PR's intent, though the false positive remains. ---- 11 / 12 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xgboost/xgboost_3.3.0.orig.tar.gz Result: main xgboost-3.3.0/src/common/param_array.cc:54:26: error: Out of bounds access in expression 'str[head]' because 'str' is empty. [containerOutOfBounds] xgboost-3.3.0/src/common/param_array.cc:47:10: note: Assuming condition is false xgboost-3.3.0/src/common/param_array.cc:54:26: note: Access out of bounds Explanation: Only the severity changed, from error to warning. The empty-string value depends on assuming the `while (!is.eof())` loop never runs, so it is a conditional value, and the PR intends such values to be reported as warnings. Also, for `std::string`, `str[0]` on an empty string is defined behaviour (it returns the terminating '\0'), so this report is doubtful to begin with. Lowering its severity is more accurate. ---- 12 / 12 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xgboost/xgboost_3.3.0.orig.tar.gz Result: your xgboost-3.3.0/src/common/param_array.cc:54:26: warning: Out of bounds access in expression 'str[head]' because 'str' is empty. [containerOutOfBounds] xgboost-3.3.0/src/common/param_array.cc:47:10: note: Assuming condition is false xgboost-3.3.0/src/common/param_array.cc:54:26: note: Access out of bounds Explanation: Only the severity changed, from error to warning; the message is the same. 'str' is empty only if the read loop never runs, i.e. the stream is already at EOF. That depends on a condition ("Assuming condition is false"), and the PR intends conditional findings to be warnings rather than errors. The finding itself is doubtful: for std::string, str[0] on an empty string returns the terminating '\0' and is well-defined. The real bug is later, at str[size()-1], which this warning does not report. So lowering the severity of this conditional and likely spurious report is an improvement.