AI review of 2026-11-13_22-15-08-a2b79ccde225-results.txt PR: #8996 https://github.com/cppcheck-opensource/cppcheck/pull/8996 Tested: a2b79ccde2256936c14d192c47a690fb02a51844 Merge base: 275e673c62902ac61e79d4151ced6a4882e50707 Reviewed: 2026-11-14 02:28:14 UTC Model: claude-opus-5-5 (effort high) Results: 5 reviewed of 9 in the report (random sample), the test is still running (100 analysed of 1000 requested packages) Verdicts: 2 improvement, 3 regression Tokens: 9843 input, 11748 cache read, 2937 cache write, 3487 output The verdicts are written by AI and can be wrong. ---- 1 / 5 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/libg/libg3d/libg3d_0.0.8.orig.tar.gz Result: your libg3d-0.0.8/plugins/import/imp_3ds/imp_3ds_callbacks.c:630:43: style: Parameter 'global' can be declared as pointer to const [constParameterPointer] Explanation: In `x3ds_cb_0xA081`, `global` is never used. The function is one of a family of 3DS chunk callbacks that all share the signature `(x3ds_global_data *global, x3ds_parent_data *parent)`. Other callbacks in the family, such as `0xA300`, do modify through `global` (`++global->max_tex_id`). These are most likely called through a function-pointer table, so making `global` const in this one callback would break the shared signature. The suggestion is therefore not actionable, and the warning is effectively a false positive. Its appearance is also suspicious: the PR only changes how compound assignments are treated, and this function only does `material->flags |= ...`, which does not involve `global`. The new warning looks like a side effect rather than better understanding of the code. The removals of the `material` warnings at lines 699 and 723 are good, but this added line is a likely false positive. ---- 2 / 5 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/libl/liblivemedia/liblivemedia_2026.11.08.orig.tar.gz Result: your live/liveMedia/RTPSource.cpp:244:28: style: The comparison 'fTotBytesReceived_lo < prevTotBytesReceived_lo' is always false because 'fTotBytesReceived_lo' and 'prevTotBytesReceived_lo' represent the same value. [knownConditionTrueFalse] live/liveMedia/RTPSource.cpp:242:39: note: 'prevTotBytesReceived_lo' is assigned value 'fTotBytesReceived_lo' here. live/liveMedia/RTPSource.cpp:244:28: note: The comparison 'fTotBytesReceived_lo < prevTotBytesReceived_lo' is always false because 'fTotBytesReceived_lo' and 'prevTotBytesReceived_lo' represent the same value. Explanation: The code saves the old value with `prev = fTotBytesReceived_lo;`, then does `fTotBytesReceived_lo += packetSize;`, then checks `fTotBytesReceived_lo < prev` to detect wrap-around. The compound assignment changes `fTotBytesReceived_lo`, so the two values are no longer the same and the comparison can be true. The PR's change to isVariableChanged skips the assignment branch for compound assignments when indirect != 0. This makes Cppcheck miss that `+=` modifies the variable here, so it keeps the 'same value' relation. The new knownConditionTrueFalse warning is a false positive. ---- 3 / 5 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/libr/libraw/libraw_0.22.3.orig.tar.gz Result: your LibRaw-LibRaw-75d1532/src/metadata/nikon.cpp:580:13: style: Variable 'cblack' can be declared as const array [constVariable] Explanation: `cblack` (a LibRaw array macro, `imgdata.color.cblack`) is written on line 580 (`cblack[...] = get2()`) and modified on line 583 (`cblack[c] -= i`), so it cannot be const. The PR stops `isVariableChanged` from treating compound assignments as modifications when `indirect != 0`. That makes the element write via `-=` invisible and produces this new false-positive constVariable warning. ---- 4 / 5 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/octave-nan/octave-nan_3.7.0.orig.tar.gz Result: your nan-3.7.0/src/linear.cpp:682:19: style: Variable 'xi' can be declared as pointer to const [constVariablePointer] Explanation: In the visible code `xi` is only read: `xi->index` and `xi->value` are read, and `xi++` changes the pointer itself, not what it points to. In upstream liblinear's MCSVM_CS solver, the later use in this scope does `xi = prob->x[i]` and writes through `w_i`, never through `xi`. So `xi` can be `const feature_node *`, and the new constVariablePointer warning looks like a true positive. The PR stops treating compound assignment as a write through the pointer, which explains why it now appears. Confidence is medium because the rest of the scope is not shown. ---- 5 / 5 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/z/zabbix/zabbix_7.0.29+dfsg.orig.tar.xz Result: your zabbix-7.0.29/src/libs/zbxcrypto/aes.c:502:11: style: Variable 'Iv' can be declared as pointer to const [constVariablePointer] Explanation: `Iv` is only read through. It is passed to `XorWithIv` as a `const uint8_t *`, reassigned to point at `buf`, and used as the source of `memcpy`. Nothing is ever written through it, so it can be declared `const uint8_t *Iv`. Before the PR, `buf += AES_BLOCKLEN` (a compound assignment to the pointer itself) was wrongly treated as changing the pointed-to data of the aliased `Iv`, which suppressed the warning. The PR fixes this, and the case matches the new test in testother.cpp. This is a correctly added true positive.