AI review of 2026-10-15_06-53-21-6820464454db-results.txt
PR:          #8880 https://github.com/cppcheck-opensource/cppcheck/pull/8880
Tested:      6820464454dbfce33f80b1cbfe3096d5845a01fc
Merge base:  a3361b3aa7b777978ae97c91256bffc431447af5
Reviewed:    2026-10-16 14:29:48 UTC
Model:       claude-opus-5-5 (effort high)
Results:     19 reviewed of 26 in the report, 7 not reviewed: valueFlowMaxIterations
Verdicts:    10 improvement, 9 regression
Tokens:      43885 input, 90375 cache read, 24100 cache write, 14238 output

The verdicts are written by AI and can be wrong.

---- 1 / 19 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/h/halide/halide_21.0.0.orig.tar.xz
Result:      your halide-21.0.0/test/performance/fan_in.cpp:35:38: error: Array 'stages[64]' accessed at index 127, which is out of bounds. [arrayIndexOutOfBounds]
     halide-21.0.0/test/performance/fan_in.cpp:27:33: note: Assignment 'i=num_stages-1', assigned value is 63
     halide-21.0.0/test/performance/fan_in.cpp:29:33: note: Assignment 'child_2=i*2+2', assigned value is 128
     halide-21.0.0/test/performance/fan_in.cpp:28:25: note: child_1 is assigned 'i*2+1' here.
     halide-21.0.0/test/performance/fan_in.cpp:29:25: note: child_2 is assigned 'i*2+2' here.
     halide-21.0.0/test/performance/fan_in.cpp:35:38: note: Array index out of bounds
Explanation: The new arrayIndexOutOfBounds warning on line 35 is a false positive. When i=63, child_3 = 129, which is >= num_stages (64), so the code takes the if-branch at line 33. The else-branch on line 35 only runs when child_3 < 64, which implies child_1 = child_3 - 2 <= 61 and child_2 <= 62. Index 127 can therefore never be reached on line 35. The PR's new symbolic +/- propagation apparently loses the link between the branch condition and the index, so Cppcheck now reports an impossible out-of-bounds access.

---- 2 / 19 ----
Verdict:     IMPROVEMENT (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/libk/libkdumpfile/libkdumpfile_0.5.6.orig.tar.gz
Result:      your libkdumpfile/tools/kdumpid/x86.c:106:11: style: Condition 'p<dd->page+0x100' is always true [knownConditionTrueFalse]
     libkdumpfile/tools/kdumpid/x86.c:104:10: note: p is assigned 'dd->page' here.
     libkdumpfile/tools/kdumpid/x86.c:107:7: note: Assuming condition is false
     libkdumpfile/tools/kdumpid/x86.c:106:11: note: Condition 'p<dd->page+0x100' is always true
Explanation: `p` is set to `dd->page` and is never changed inside the loop. `memcmp` does not modify anything, so `p < dd->page + 0x100` is always true. That means the loop either returns on the first iteration or spins forever: the source forgot to increment `p`. The new symbolic tracking of `dd->page + 0x100` lets Cppcheck see this, so the added warning is a true positive that points at a real bug.

---- 3 / 19 ----
Verdict:     IMPROVEMENT (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/n/netpbm-free/netpbm-free_11.15.04+ds.orig.tar.xz
Result:      your netpbm-free-11.15.04/converter/other/jpeg2000/libjasper/jpc/jpc_t2enc.c:360:25: style: Variable 'lastpass' is assigned an expression that holds the same value. [redundantAssignment]
     netpbm-free-11.15.04/converter/other/jpeg2000/libjasper/jpc/jpc_t2enc.c:338:34: note: lastpass is assigned 'endpass-1' here.
     netpbm-free-11.15.04/converter/other/jpeg2000/libjasper/jpc/jpc_t2enc.c:355:45: note: Assuming condition is false
     netpbm-free-11.15.04/converter/other/jpeg2000/libjasper/jpc/jpc_t2enc.c:360:25: note: Variable 'lastpass' is assigned an expression that holds the same value.
Explanation: Line 338 sets `lastpass = endpass - 1`. Between line 338 and line 360, neither `lastpass` nor `endpass` is changed: the loop only advances `pass`, and `jpc_putcommacode`/`numlenbits` touch other data. So `lastpass = endpass - 1` at line 360 assigns the value `lastpass` already holds. The PR's new symbolic tracking (`endpass` == `lastpass`+1, so `endpass-1` == `lastpass`+0) lets Cppcheck see this. The new redundantAssignment style warning is a correct, harmless true positive.

---- 4 / 19 ----
Verdict:     IMPROVEMENT (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/p/parasail/parasail_2.6.2+dfsg.orig.tar.xz
Result:      your parasail-2.6.2/src/sg_stats_scan.c:341:17: style: Variable 'end_ref' is assigned an expression that holds the same value. [redundantAssignment]
     parasail-2.6.2/src/sg_stats_scan.c:336:47: note: Assuming that condition 'end_ref==s2Len-1' is not redundant
     parasail-2.6.2/src/sg_stats_scan.c:336:47: note: Assuming that condition 'end_ref==s2Len-1' is not redundant
     parasail-2.6.2/src/sg_stats_scan.c:341:17: note: Variable 'end_ref' is assigned an expression that holds the same value.
Explanation: Line 341 is inside the `else if` branch guarded by `end_ref == s2Len-1`. Neither `end_ref` nor `s2Len` changes before line 341, so `end_ref = s2Len-1;` stores a value `end_ref` already holds and is redundant. The pull request adds symbolic value propagation through `+`/`-` with a constant, which lets Cppcheck see that the two `s2Len-1` expressions are equal. The new warning is a true positive (style).

---- 5 / 19 ----
Verdict:     REGRESSION (low confidence)
Package:     https://ftp.debian.org/debian/pool/main/p/prelude-lml/prelude-lml_5.2.0.orig.tar.gz
Result:      your prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:121:17: style: Variable 'src' is assigned an expression that holds the same value. [redundantAssignment]
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:114:21: note: src is assigned 'input+2' here.
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:117:17: note: Assuming condition is false
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:119:17: note: Assuming condition is false
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:121:17: note: Variable 'src' is assigned an expression that holds the same value.
Explanation: Line 114 sets `src = input + 2`. Line 116 passes `&src` to mbsrtowcs, which may change it. Line 118 then only checks with the gnulib ASSERT macro that it did not. Line 121 resets `src = input + 2` before the next call. The new warning only holds if Cppcheck treats the ASSERT check (abort on failure) as a guarantee about `src`; the notes show it reached this by 'assuming' those ASSERT conditions are false. In test code, resetting the pointer after an assert is deliberate and harmless, so the warning reads as noise rather than a real redundancy. It comes from the new symbolic +/- values added by this PR, which now link `src` to `input+2` across the call. It is technically defensible if ASSERT is taken as always passing, so confidence is low.

---- 6 / 19 ----
Verdict:     IMPROVEMENT (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/p/prelude-lml/prelude-lml_5.2.0.orig.tar.gz
Result:      your prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:166:17: style: Variable 'src' is assigned an expression that holds the same value. [redundantAssignment]
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:159:21: note: src is assigned 'input+2' here.
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:162:17: note: Assuming condition is false
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:164:17: note: Assuming condition is false
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:166:17: note: Variable 'src' is assigned an expression that holds the same value.
Explanation: Line 159 sets `src = input + 2`, and `mbsrtowcs(NULL, &src, ...)` may change it. But line 163, `ASSERT (src == input + 2)`, uses gnulib's ASSERT, which calls abort() on failure. So on every path that reaches line 166, `src` already equals `input + 2`. The PR's new symbolic arithmetic for `input + 2` lets Cppcheck see this, so the reset at line 166 really does assign the value `src` already holds. The warning is factually correct, though in test code the reset is a harmless defensive habit, so its practical value is modest.

---- 7 / 19 ----
Verdict:     IMPROVEMENT (low confidence)
Package:     https://ftp.debian.org/debian/pool/main/p/prelude-lml/prelude-lml_5.2.0.orig.tar.gz
Result:      your prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:220:17: style: Variable 'src' is assigned an expression that holds the same value. [redundantAssignment]
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:213:21: note: src is assigned 'input+4' here.
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:216:17: note: Assuming condition is false
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:218:17: note: Assuming condition is false
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:220:17: note: Variable 'src' is assigned an expression that holds the same value.
Explanation: At line 213 `src = input + 4`. `&src` is passed to mbsrtowcs, so src could change. But line 217 then runs `ASSERT (src == input + 4)`, and gnulib's ASSERT calls abort() when the check fails. So at line 220 src is known to equal `input + 4`, and reassigning the same value really is redundant. The PR's new symbolic +/- propagation lets Cppcheck connect `input + 4` with the asserted value of src. The warning is technically correct, though in test code the reset is a deliberate readability choice, so its practical value is limited.

---- 8 / 19 ----
Verdict:     IMPROVEMENT (low confidence)
Package:     https://ftp.debian.org/debian/pool/main/p/prelude-lml/prelude-lml_5.2.0.orig.tar.gz
Result:      your prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:265:17: style: Variable 'src' is assigned an expression that holds the same value. [redundantAssignment]
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:258:21: note: src is assigned 'input+2' here.
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:261:17: note: Assuming condition is false
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:263:17: note: Assuming condition is false
     prelude-lml-5.2.0/libmissing/tests/test-mbsrtowcs.c:265:17: note: Variable 'src' is assigned an expression that holds the same value.
Explanation: At line 258 `src` is set to `input + 2`. Its address is then passed to mbsrtowcs, and line 262 has `ASSERT (src == input + 2)`. The gnulib ASSERT aborts when its condition fails, so at line 265 `src` is guaranteed to already equal `input + 2`. The reassignment is therefore redundant, and the PR's new symbolic offset tracking for `input + 2` lets Cppcheck see this correctly. The warning is technically accurate. Its practical value is limited, though: this is test code where the reset is deliberately defensive, so some users may see it as noise.

---- 9 / 19 ----
Verdict:     IMPROVEMENT (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/p/psautohint/psautohint_2.4.0.orig.tar.gz
Result:      your psautohint-2.4.0/libpsautohint/autohintexe.c:457:9: style: Variable 'argi' is assigned an expression that holds the same value. [redundantAssignment]
     psautohint-2.4.0/libpsautohint/autohintexe.c:396:10: note: argi is assigned 'firstFileNameIndex-1' here.
     psautohint-2.4.0/libpsautohint/autohintexe.c:397:9: note: Assuming condition is false
     psautohint-2.4.0/libpsautohint/autohintexe.c:457:9: note: Variable 'argi' is assigned an expression that holds the same value.
Explanation: Line 396 sets `argi = firstFileNameIndex - 1`, then the if at 397 branches. The else branch starts at line 443 and repeats the same assignment at 457 before touching `argi`. On that path `argi` already holds `firstFileNameIndex - 1`, so the second assignment really is redundant. The PR's new symbolic arithmetic for `+`/`-` with constants lets Cppcheck see that the two expressions are equal. This looks like a correct new style finding (true positive), assuming the condition at 397 does not modify `argi` or `firstFileNameIndex`; that line is not shown.

---- 10 / 19 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/s/scamp/scamp_2.15.0.orig.tar.gz
Result:      your astromatic-scamp-29b4ac6/src/proper.c:492:19: warning: Expression 'ncoeff' can have a negative value. That is converted to an unsigned value and used in an unsigned calculation. [signConversionCond]
     astromatic-scamp-29b4ac6/src/proper.c:542:9: note: Assuming that condition 'paralflag' is not redundant
     astromatic-scamp-29b4ac6/src/proper.c:489:3: note: Assignment from 'ncoeffp1=ncoeff+1'
     astromatic-scamp-29b4ac6/src/proper.c:489:12: note: ncoeffp1 is assigned 'ncoeff+1' here.
     astromatic-scamp-29b4ac6/src/proper.c:492:19: note: Negative value is converted to an unsigned value
Explanation: At line 488, ncoeff is set to `paralflag ? 5 : 4`, so it is always 4 or 5 at the memset on line 492 and can never be negative. The new signConversionCond warning is a false positive. Its trace goes through the new symbolic value from `ncoeffp1 = ncoeff+1`, which suggests the PR's symbolic +/- propagation produced a bogus negative value for ncoeff.

---- 11 / 19 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/s/spooles/spooles_2.2.orig.tar.gz
Result:      your InpMtx/src/fullAdj.c:178:16: style: Variable 'ip' is assigned an expression that holds the same value. [redundantAssignment]
     InpMtx/src/fullAdj.c:177:23: note: freeIP is assigned 'baseIP+1' here.
     InpMtx/src/fullAdj.c:178:16: note: Variable 'ip' is assigned an expression that holds the same value.
Explanation: At line 176 `baseIP = ip`, then line 177 sets `freeIP = baseIP + 1`, so `freeIP` holds `ip + 1`. The assignment `ip = freeIP` at line 178 therefore changes `ip` to the next element; it does not assign the same value. The PR's new symbolic +/- propagation now gives `baseIP + 1` a symbolic value of `ip` with offset 1. The redundantAssignment check apparently treats that as 'same value' and ignores the non-zero offset. This is a new false positive, repeated six times in this file.

---- 12 / 19 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/s/spooles/spooles_2.2.orig.tar.gz
Result:      your InpMtx/src/fullAdj.c:320:16: style: Variable 'ip' is assigned an expression that holds the same value. [redundantAssignment]
     InpMtx/src/fullAdj.c:319:23: note: freeIP is assigned 'baseIP+1' here.
     InpMtx/src/fullAdj.c:320:16: note: Variable 'ip' is assigned an expression that holds the same value.
Explanation: Just before line 320, `ip == baseIP` (via `baseIP = ip`) and `freeIP == baseIP + 1`. So `ip = freeIP` moves `ip` from `baseIP` to `baseIP + 1`. It changes the value and is not redundant. The PR's new symbolic propagation for `+`/`-` with a non-zero constant gives `baseIP + 1` the symbolic value `ip+1`. The redundantAssignment check then appears to treat that offset symbolic value as the same value as `ip`. This is a new false positive.

---- 13 / 19 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/s/spooles/spooles_2.2.orig.tar.gz
Result:      your InpMtx/src/fullAdj.c:347:16: style: Variable 'ip' is assigned an expression that holds the same value. [redundantAssignment]
     InpMtx/src/fullAdj.c:346:23: note: freeIP is assigned 'baseIP+1' here.
     InpMtx/src/fullAdj.c:347:16: note: Variable 'ip' is assigned an expression that holds the same value.
Explanation: At line 344–345 `ip` is set by `IP_init()` and then `baseIP = ip`, so `ip == baseIP`. Line 346 sets `freeIP = baseIP + 1`. The assignment `ip = freeIP` at line 347 therefore changes `ip` from `baseIP` to `baseIP + 1`; it is not redundant. The new symbolic +/- offset propagation in valueflow appears to mishandle the +1 offset, so Cppcheck wrongly treats the values as equal. This adds a new false positive, and the same pattern appears six times in this file.

---- 14 / 19 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/s/spooles/spooles_2.2.orig.tar.gz
Result:      your InpMtx/src/fullAdj.c:434:16: style: Variable 'ip' is assigned an expression that holds the same value. [redundantAssignment]
     InpMtx/src/fullAdj.c:433:23: note: freeIP is assigned 'baseIP+1' here.
     InpMtx/src/fullAdj.c:434:16: note: Variable 'ip' is assigned an expression that holds the same value.
Explanation: Before line 434, `ip` holds the new block (`ip = IP_init(...)`, `baseIP = ip`), and `freeIP` was just set to `baseIP + 1`. So `ip = freeIP` moves `ip` from `baseIP` to `baseIP + 1`, a different address. The assignment is needed and not redundant. The new symbolic +/- propagation for pointers apparently makes Cppcheck treat `ip` and `freeIP` as equal. The new redundantAssignment warning is a false positive.

---- 15 / 19 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/s/spooles/spooles_2.2.orig.tar.gz
Result:      your InpMtx/src/fullAdj.c:480:16: style: Variable 'ip' is assigned an expression that holds the same value. [redundantAssignment]
     InpMtx/src/fullAdj.c:479:23: note: freeIP is assigned 'baseIP+1' here.
     InpMtx/src/fullAdj.c:480:16: note: Variable 'ip' is assigned an expression that holds the same value.
Explanation: At line 480, `ip` still holds `baseIP`, because line 478 did `baseIP = ip`. `freeIP` is `baseIP + 1` (line 479). So `ip = freeIP` changes `ip` from `baseIP` to `baseIP + 1`; it is not a redundant assignment. The new symbolic +/- propagation in valueflow wrongly concludes that `ip` and `freeIP` hold the same value. This is a new false positive, and the same pattern produces six of them in this file.

---- 16 / 19 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/s/spooles/spooles_2.2.orig.tar.gz
Result:      your InpMtx/src/fullAdj.c:91:16: style: Variable 'ip' is assigned an expression that holds the same value. [redundantAssignment]
     InpMtx/src/fullAdj.c:90:23: note: freeIP is assigned 'baseIP+1' here.
     InpMtx/src/fullAdj.c:91:16: note: Variable 'ip' is assigned an expression that holds the same value.
Explanation: Before line 91, `ip` equals `baseIP` (set via `baseIP = ip`), and `freeIP` is `baseIP + 1`. So `ip = freeIP` moves `ip` from `baseIP` to `baseIP + 1`, a different address, and the assignment is not redundant. The PR's new symbolic +/- propagation apparently gives `baseIP + 1` a wrong symbolic value, which makes `freeIP` look equal to `ip`. This is a new false positive.

---- 17 / 19 ----
Verdict:     IMPROVEMENT (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/t/trf/trf_4.09.1.orig.tar.gz
Result:      your TRF-4.09.1/src/tr30dat.c:2468:2: style: Variable 'end' is assigned an expression that holds the same value. [redundantAssignment]
     TRF-4.09.1/src/tr30dat.c:2456:6: note: end is assigned 'length-2' here.
     TRF-4.09.1/src/tr30dat.c:2464:6: note: Assignment 'n=end', assigned value is symbolic=length-2
     TRF-4.09.1/src/tr30dat.c:2456:6: note: end is assigned 'length-2' here.
     TRF-4.09.1/src/tr30dat.c:2464:4: note: n is assigned 'end' here.
     TRF-4.09.1/src/tr30dat.c:2468:2: note: Variable 'end' is assigned an expression that holds the same value.
Explanation: Line 2456 sets `end = length-2`. Nothing between line 2456 and line 2468 changes `end` or `length`: the loop only reads `end`, and `n = end` only reads it. So `end = length-2` at line 2468 stores the value `end` already holds, and the assignment is genuinely redundant. This is a correct new style warning (a true positive), made possible by the improved symbolic value tracking for `+`/`-` in the PR. The note chain (mentioning `n=end`) is somewhat noisy, but the warning itself is accurate.

---- 18 / 19 ----
Verdict:     IMPROVEMENT (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/t/trf/trf_4.09.1.orig.tar.gz
Result:      your TRF-4.09.1/src/tr30dat.c:2475:2: style: Variable 'end' is assigned an expression that holds the same value. [redundantAssignment]
     TRF-4.09.1/src/tr30dat.c:2456:6: note: end is assigned 'length-2' here.
     TRF-4.09.1/src/tr30dat.c:2464:6: note: Assignment 'n=end', assigned value is symbolic=length-2
     TRF-4.09.1/src/tr30dat.c:2456:6: note: end is assigned 'length-2' here.
     TRF-4.09.1/src/tr30dat.c:2464:4: note: n is assigned 'end' here.
     TRF-4.09.1/src/tr30dat.c:2475:2: note: Variable 'end' is assigned an expression that holds the same value.
Explanation: Line 2468 sets `end = length-2`. The following loop only writes `counts[i]` and the loop counter `i`; it changes neither `end` nor `length`. So at line 2475 `end` already equals `length-2`, and the reassignment really is redundant. The PR adds symbolic values for `x +/- constant`, which lets Cppcheck see this. The new style warning is a true positive. The notes pointing to line 2456 and `n=end` are a bit roundabout, but the conclusion is correct. The redundancy is harmless and was probably written for readability.

---- 19 / 19 ----
Verdict:     IMPROVEMENT (low confidence)
Package:     https://ftp.debian.org/debian/pool/main/x/xfce4-settings/xfce4-settings_4.20.5.orig.tar.bz2
Result:      your xfce4-settings-4.20.5/dialogs/display-settings/main.c:2891:9: style: Variable 'available_w' is assigned an expression that holds the same value. [redundantAssignment]
     xfce4-settings-4.20.5/dialogs/display-settings/main.c:2847:17: note: available_w is assigned 'w*scale+0.5-6' here.
     xfce4-settings-4.20.5/dialogs/display-settings/main.c:2862:35: note: Assuming condition is false
     xfce4-settings-4.20.5/dialogs/display-settings/main.c:2875:35: note: Assuming condition is false
     xfce4-settings-4.20.5/dialogs/display-settings/main.c:2883:9: note: Assuming condition is true
     xfce4-settings-4.20.5/dialogs/display-settings/main.c:2891:9: note: Variable 'available_w' is assigned an expression that holds the same value.
Explanation: Line 2847 sets `available_w = w * scale + 0.5 - 6`. In the shown code, `w`, `scale` and `available_w` are not changed between line 2847 and line 2891. Line 2855 only reads `available_w`, and the `pango_layout_get_pixel_extents` call changes `ink_extent`/`log_extent`, not these variables. So the reassignment at 2891 stores the same value again, and the new redundantAssignment warning is technically correct. It is a low-impact style finding: the recomputation is likely deliberate for readability. Lines 2848-2850 are not visible, so it cannot be fully confirmed that nothing in between changes `w` or `scale`. Some caution is also warranted because the new symbolic arithmetic is being applied to a floating-point expression.