AI review of 2026-10-05_07-31-15-7f232989d1f9-results.txt PR: #8880 https://github.com/cppcheck-opensource/cppcheck/pull/8880 Tested: 7f232989d1f95849f025d1f3e7599b087d19e8cc Merge base: c83bee72c5ec893aa28450f22b0959f0b84726b0 Reviewed: 2026-10-09 01:56:05 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 122 in the report (random sample), 45 not reviewed: valueFlowMaxIterations Verdicts: 37 improvement, 11 regression, 2 unclear Tokens: 157124 input, 106134 cache read, 20216 cache write, 35609 output The verdicts are written by AI and can be wrong. ---- 1 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-h8300-hms/binutils-h8300-hms_2.16.1.orig.tar.gz Result: your binutils-h8300-hms-2.16.1/gas/config/obj-vms.c:2205:3: style: Variable 'pnt' is assigned an expression that holds the same value. [redundantAssignment] binutils-h8300-hms-2.16.1/gas/config/obj-vms.c:2175:7: note: pnt is assigned 'str+1' here. binutils-h8300-hms-2.16.1/gas/config/obj-vms.c:2177:19: note: Assuming condition is false binutils-h8300-hms-2.16.1/gas/config/obj-vms.c:2205:3: note: Variable 'pnt' is assigned an expression that holds the same value. Explanation: The listing is shifted by about 9 lines. The note's line 2175 matches the first `pnt = str + 1;` (shown at 2184), and the flagged line 2205 matches the second `pnt = str + 1;` (shown at 2214). Between them is only `if (*pnt >= '0' && *pnt <= '9') {...}`, and every path inside that block returns. `type_check` (a strcmp on str) and `cvt_integer` writing into `pnt1` leave both `pnt` and `str` unchanged. So whenever execution reaches the second assignment, `pnt` already equals `str + 1`, and the reassignment really is redundant. The PR's new symbolic offset tracking (`str+1` relating to `pnt`) is what enables this correct finding. It is a new true positive, though only a minor style issue. ---- 2 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/bzip3/bzip3_1.5.3.orig.tar.gz Result: your bzip3-1.5.3/src/libbz3.c:679:33: style: Condition 'compressed_size-8>buffer_size' is always false [knownConditionTrueFalse] bzip3-1.5.3/src/libbz3.c:658:40: note: Assuming that condition 'buffer_sizebuffer_size' is always false Explanation: Line 658 returns early unless buffer_size >= compressed_size, and line 673 returns early unless compressed_size >= 8. So at line 679, compressed_size - 8 is non-negative and smaller than compressed_size, which is <= buffer_size. The check 'compressed_size-8 > buffer_size' therefore can never be true. The signed/size_t conversion does not change this, because compressed_size - 8 >= 0 there. The PR's new symbolic offset tracking for +/- lets Cppcheck see this, so the new warning correctly flags a redundant defensive check (a true positive style finding). ---- 3 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/clifm/clifm_1.29.orig.tar.gz Result: your clifm-1.29/src/fast_magic.c:3734:26: style: Condition 'slen>frame2_offset' is always true [knownConditionTrueFalse] clifm-1.29/src/fast_magic.c:3726:11: note: Assuming that condition 'slenframe2_offset' is always true Explanation: Line 3726 returns early unless `slen >= frame1_len + 6 + 4`. So at line 3733, `frame2_offset = frame1_len + 6` is at most `slen - 4`, and `slen > frame2_offset` is always true. Overflow is not possible because `frame1_len` comes from a uint16 difference and is at most 65536. The note's symbolic bound (`frame2_offset < slen-3`) is also correct. The ternary is redundant defensive code, so this is a valid new knownConditionTrueFalse finding enabled by the new symbolic `+`/`-` value propagation. ---- 4 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/d/dasher/dasher_5.0.0~beta~repack2.orig.tar.xz Result: your dasher-5.0.0~beta~repack2/Src/DasherCore/TwoButtonDynamicFilter.cpp:84:3: style: Variable 'iDasherY' is assigned an expression that holds the same value. [redundantAssignment] dasher-5.0.0~beta~repack2/Src/DasherCore/TwoButtonDynamicFilter.cpp:79:12: note: iDasherY is assigned '2048+GetLongParameter(LP_TWO_BUTTON_OFFSET)' here. dasher-5.0.0~beta~repack2/Src/DasherCore/TwoButtonDynamicFilter.cpp:84:3: note: Variable 'iDasherY' is assigned an expression that holds the same value. Explanation: Line 79 sets iDasherY to 2048 + GetLongParameter(LP_TWO_BUTTON_OFFSET). It is then only passed by value to Dasher2Screen, which writes only the screen coordinates. Line 84 assigns exactly the same expression again, so the second assignment really does store the same value and is redundant. The PR's new symbolic values for '+ constant' let Cppcheck see this. The warning is a true positive, though mostly stylistic: the code repeats the assignment for symmetry. It relies on the settings value not changing between the two calls, which holds in practice, hence medium confidence. ---- 5 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/e/epics-base/epics-base_7.0.8.1+dfsg1.orig.tar.xz Result: your base-7.0.8.1/modules/libcom/src/osi/os/RTEMS-score/osdThread.c:118:5: style: Variable 'newPriority' is assigned an expression that holds the same value. [redundantAssignment] base-7.0.8.1/modules/libcom/src/osi/os/RTEMS-score/osdThread.c:116:26: note: newPriority is assigned 'priority+1' here. base-7.0.8.1/modules/libcom/src/osi/os/RTEMS-score/osdThread.c:118:5: note: Variable 'newPriority' is assigned an expression that holds the same value. Explanation: Line 116 initializes newPriority = priority + 1, and line 118 assigns the same expression again. Nothing modifies priority or newPriority in between, so the second assignment is truly redundant. The PR adds symbolic values for +/- with a constant, which lets Cppcheck see that newPriority already holds priority+1. This is a correct new true positive. ---- 6 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/e/epics-base/epics-base_7.0.8.1+dfsg1.orig.tar.xz Result: your base-7.0.8.1/modules/libcom/src/osi/os/vxWorks/osdThread.c:402:5: style: Variable 'newPriority' is assigned an expression that holds the same value. [redundantAssignment] base-7.0.8.1/modules/libcom/src/osi/os/vxWorks/osdThread.c:400:26: note: newPriority is assigned 'priority+1' here. base-7.0.8.1/modules/libcom/src/osi/os/vxWorks/osdThread.c:402:5: note: Variable 'newPriority' is assigned an expression that holds the same value. Explanation: In epicsThreadLowestPriorityLevelAbove, `newPriority` is initialized with `priority + 1` and then immediately assigned `priority + 1` again, with no change to `priority` in between. The second assignment really is redundant. The new symbolic value for `priority + 1` added by the PR lets Cppcheck see this, so the new warning is a true positive. The reported line numbers are offset by about 2 lines from the shown source, but the flagged pattern clearly matches the code. ---- 7 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/fastlink/fastlink_4.1P-fix100+dfsg.orig.tar.xz Result: your fastlink/4.1P/src/ilink.c:621:7: style: Variable 'FORLIM' is assigned an expression that holds the same value. [redundantAssignment] fastlink/4.1P/src/ilink.c:613:12: note: FORLIM is assigned 'mlocus-2' here. fastlink/4.1P/src/ilink.c:620:9: note: Assuming condition is true fastlink/4.1P/src/ilink.c:621:7: note: Variable 'FORLIM' is assigned an expression that holds the same value. Explanation: Line 613 sets `FORLIM = mlocus - 2`. Between that line and line 621, the code only calls `fprintf`/`putc` and runs a loop over `i`. Neither `FORLIM` nor `mlocus` is modified. So `FORLIM` already holds `mlocus - 2` at line 621, and the second assignment really is redundant. The PR's new symbolic value for `x + c` / `x - c` lets Cppcheck track this correctly. The warning is accurate, though it is low-value style noise in p2c-generated code. ---- 8 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/fastlink/fastlink_4.1P-fix100+dfsg.orig.tar.xz Result: your fastlink/4.1P/src/lodscore.c:528:5: style: Variable 'FORLIM' is assigned an expression that holds the same value. [redundantAssignment] fastlink/4.1P/src/lodscore.c:521:10: note: FORLIM is assigned 'mlocus-2' here. fastlink/4.1P/src/lodscore.c:526:7: note: Assuming condition is true fastlink/4.1P/src/lodscore.c:528:5: note: Variable 'FORLIM' is assigned an expression that holds the same value. Explanation: FORLIM is set to `mlocus - 2` at line 521. Between there and line 528 nothing writes to FORLIM or mlocus: the loop only changes i and calls fprintf, and WITH1 is a different variable. So the second `FORLIM = mlocus - 2` really does assign the value FORLIM already holds. The PR adds symbolic values for `+`/`-` with a constant, which lets redundantAssignment see this. The warning is technically correct. It is low-value in this machine-translated (p2c-style) code, but it is not a false positive. ---- 9 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/fastlink/fastlink_4.1P-fix100+dfsg.orig.tar.xz Result: your fastlink/4.1P/src/lodscore.c:658:3: style: Variable 'FORLIM' is assigned an expression that holds the same value. [redundantAssignment] fastlink/4.1P/src/lodscore.c:652:10: note: FORLIM is assigned 'mlocus-2' here. fastlink/4.1P/src/lodscore.c:658:3: note: Variable 'FORLIM' is assigned an expression that holds the same value. Explanation: Line 652 sets `FORLIM = mlocus - 2`. Between 652 and 658 the code only runs a read-only loop with `fprintf`, an `if` that calls `fprintf`, and `WITH = femaletheta`. Neither `FORLIM` nor `mlocus` (a global int) is written. So `FORLIM` still holds `mlocus - 2` when line 658 assigns the same expression again, and that assignment really is redundant. The new symbolic +/- offset propagation lets Cppcheck see that `mlocus - 2` equals FORLIM's current symbolic value. The warning is technically a true positive, though low-value: this is p2c-generated loop-limit code where the repetition is harmless. ---- 10 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/fastlink/fastlink_4.1P-fix100+dfsg.orig.tar.xz Result: your fastlink/4.1P/src/loinputcode.c:41:7: style: Variable 'FORLIM' is assigned an expression that holds the same value. [redundantAssignment] fastlink/4.1P/src/loinputcode.c:33:10: note: FORLIM is assigned 'mlocus-2' here. fastlink/4.1P/src/loinputcode.c:38:7: note: Assuming condition is true fastlink/4.1P/src/loinputcode.c:39:9: note: Assuming condition is true fastlink/4.1P/src/loinputcode.c:41:7: note: Variable 'FORLIM' is assigned an expression that holds the same value. Explanation: Line 33 sets `FORLIM = mlocus - 2`. The only code between that and line 41 is a loop that increments k and writes `WITH->theta[i]` (doubles). Nothing there modifies `mlocus` or `FORLIM`: no function calls, and `mlocus` is not written. So the second `FORLIM = mlocus - 2` really does assign the value FORLIM already holds. The PR's new symbolic offset values for `+`/`-` let Cppcheck see that `mlocus - 2` equals FORLIM. The warning is technically correct, though in this p2c-style generated code the reassignment is harmless, so it may be seen as low-value noise. ---- 11 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/fastlink/fastlink_4.1P-fix100+dfsg.orig.tar.xz Result: your fastlink/4.1P/src/loinputcode.c:469:7: style: Variable 'FORLIM' is assigned an expression that holds the same value. [redundantAssignment] fastlink/4.1P/src/loinputcode.c:457:10: note: FORLIM is assigned 'nlocus-2' here. fastlink/4.1P/src/loinputcode.c:466:7: note: Assuming condition is true fastlink/4.1P/src/loinputcode.c:467:9: note: Assuming condition is true fastlink/4.1P/src/loinputcode.c:469:7: note: Variable 'FORLIM' is assigned an expression that holds the same value. Explanation: Line 457 sets `FORLIM = nlocus - 2`. The loop at 458–465 only writes `k`, `xall[]` and the local `bndtype[]`; neither `FORLIM` nor `nlocus` changes. So at line 469 `FORLIM` already equals `nlocus - 2`, and reassigning it is redundant. The PR's new symbolic offset values (`nlocus` with offset -2) let Cppcheck see this. The warning is a correct style finding, though in p2c-generated code it is low value. ---- 12 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/fastlink/fastlink_4.1P-fix100+dfsg.orig.tar.xz Result: your fastlink/4.1P/src/mlink.c:248:7: style: Variable 'FORLIM' is assigned an expression that holds the same value. [redundantAssignment] fastlink/4.1P/src/mlink.c:240:12: note: FORLIM is assigned 'mlocus-2' here. fastlink/4.1P/src/mlink.c:246:9: note: Assuming condition is true fastlink/4.1P/src/mlink.c:248:7: note: Variable 'FORLIM' is assigned an expression that holds the same value. Explanation: Line 240 sets `FORLIM = mlocus - 2`. Between there and line 248, the code only runs a `for` loop that changes `i`, not `FORLIM`, plus some `printf`/`putchar` calls. Nothing changes `mlocus` either. So `FORLIM` already holds `mlocus - 2` when line 248 assigns it again, and that assignment is redundant. The PR now tracks symbolic values through `x - constant`, which lets Cppcheck see this. The new warning is technically correct. It is low-value noise in p2c-generated code, but it is not a false positive. ---- 13 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gamazons/gamazons_0.83.orig.tar.gz Result: your gamazons-0.83/src/unit-test.c:225:31: error: Shifting 32-bit value by 98 bits is undefined behaviour [shiftTooManyBits] gamazons-0.83/src/unit-test.c:43:15: note: Assuming that condition 'i<100' is not redundant gamazons-0.83/src/unit-test.c:46:52: note: Calling function 'psvec', 2nd argument '(diag<10)?diag+1:(10-diag/10)' value is 99 gamazons-0.83/src/unit-test.c:223:15: note: Assignment 'i=len-1', assigned value is 98 gamazons-0.83/src/unit-test.c:225:31: note: Shift Explanation: The new warning depends on psvec() receiving len=99 from the argument '(diag<10)?diag+1:(10-diag/10)'. That argument cannot be 99. In the true branch diag<10, so diag+1 is at most 10. In the false branch 10-diag/10 is small. So len is at most about 10, and the shift amount stays well below 32. The 99 most likely comes from the PR's new symbolic '+constant' values being misapplied, which makes this a newly added false positive. ---- 14 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gimp/gimp_3.2.6.orig.tar.xz Result: your gimp-3.2.6/app/core/gimplineart.c:1841:19: style: Variable 'p2y' is assigned an expression that holds the same value. [redundantAssignment] gimp-3.2.6/app/core/gimplineart.c:1826:23: note: p2y is assigned 'p->y+1' here. gimp-3.2.6/app/core/gimplineart.c:1841:19: note: Variable 'p2y' is assigned an expression that holds the same value. Explanation: Line 1826 sets `p2y = p->y + 1`. Between 1826 and 1841, `p2y` and `p->y` are not changed. The `if` block only writes to a freshly allocated `p2`, pushes it onto the queue, and sets `visited[]`. So `p2y = p->y + 1` at 1841 assigns the value `p2y` already holds. The new symbolic value for `p->y + 1` from the PR lets Cppcheck see this. The warning is technically correct, but low value, since the code repeats the assignment on purpose to keep the neighbour-checking blocks symmetric. ---- 15 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gimp/gimp_3.2.6.orig.tar.xz Result: your gimp-3.2.6/app/core/gimplineart.c:1870:19: style: Variable 'p2x' is assigned an expression that holds the same value. [redundantAssignment] gimp-3.2.6/app/core/gimplineart.c:1855:23: note: p2x is assigned 'p->x-1' here. gimp-3.2.6/app/core/gimplineart.c:1870:19: note: Variable 'p2x' is assigned an expression that holds the same value. Explanation: Line 1855 sets `p2x = p->x - 1`. Between 1855 and 1870 the code only reads `p2x`; the writes go to the newly allocated `p2` and to `visited[]`, not to `p` or `p2x`. So the assignment at 1870 stores the value `p2x` already holds, and the warning is factually correct. The PR's new symbolic offset tracking for `p->x - 1` makes this detectable. The code is written symmetrically on purpose for readability, so the finding is of limited practical use, but it is not a false positive. ---- 16 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/got/got_0.126.orig.tar.gz Result: main got-portable-0.126/lib/sigs.c:142:13: style: Variable 'gt' can be declared as pointer to const [constVariablePointer] Explanation: In signer_identity(), 'gt' is only assigned from strrchr() and then used in comparisons (lt+1 < gt) and pointer arithmetic (gt-lt-2). It is never written through, so declaring it 'const char *gt' is valid and the constVariablePointer warning was a true positive. The PR adds new symbolic values for '+'/'-' expressions such as lt+1 and gt-lt, and this apparently changes how the const-pointer check sees 'gt'. Nothing in the code justifies dropping the warning, so a true positive was lost. ---- 17 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/k/kodi-screensaver-shadertoy/kodi-screensaver-shadertoy_21.0.2+ds.orig.tar.xz Result: your kodi-screensaver-shadertoy-21.0.2/src/lodepng.cpp:4290:22: style: Condition 'string2_begin>chunkLength' is always false [knownConditionTrueFalse] kodi-screensaver-shadertoy-21.0.2/src/lodepng.cpp:4278:19: note: Assuming that condition 'length+2>=chunkLength' is not redundant kodi-screensaver-shadertoy-21.0.2/src/lodepng.cpp:4279:19: note: Assuming condition is false kodi-screensaver-shadertoy-21.0.2/src/lodepng.cpp:4282:8: note: Assuming condition is false kodi-screensaver-shadertoy-21.0.2/src/lodepng.cpp:4287:25: note: Assuming condition is false kodi-screensaver-shadertoy-21.0.2/src/lodepng.cpp:4289:19: note: string2_begin is assigned 'length+2' here. kodi-screensaver-shadertoy-21.0.2/src/lodepng.cpp:4290:22: note: Condition 'string2_begin>chunkLength' is always false Explanation: Line 4278 breaks out of the loop when `length + 2 >= chunkLength`. Every later path therefore has `length + 2 < chunkLength`. Line 4289 sets `string2_begin = length + 2`, so `string2_begin > chunkLength` at line 4290 can never be true. There is no overflow, because `length` is at most 79 at that point. The check is genuinely redundant, so this is a true positive. The PR's new symbolic value tracking for `+`/`-` with a constant lets Cppcheck see this. ---- 18 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/l/lynx/lynx_2.9.3.orig.tar.bz2 Result: main lynx2.9.3/WWW/Library/Implementation/HTFTP.c:2112:11: style: Variable 'end' can be declared as pointer to const [constVariablePointer] Explanation: In parse_cms_dir_entry, `end = line + strlen(line)` is only used as an upper bound in comparisons such as `cp < end` and `cps < end`. Nothing is ever written through it, so declaring it `const char *end` is valid and the constVariablePointer warning in main is a true positive. The PR adds symbolic values on `+`/`-` expressions, which appears to change how cppcheck analyses `end`. It is not a better understanding of this code, so losing the warning is a regression. Confidence is medium because the rest of the function is not shown. ---- 19 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/libe/libembperl-perl/libembperl-perl_2.5.0.orig.tar.gz Result: your Embperl-2.5.0/epcomp.c:320:30: warning: Invalid strncasecmp() argument nr 3. The value is -1 but the valid values are '0:'. [invalidFunctionArg] Embperl-2.5.0/epcomp.c:318:6: note: or is assigned 'strchr(eq+1,'|')' here. Embperl-2.5.0/epcomp.c:320:36: note: Assuming condition is false Embperl-2.5.0/epcomp.c:322:10: note: Assuming condition is false Embperl-2.5.0/epcomp.c:324:6: note: eq is assigned 'or+1' here. Embperl-2.5.0/epcomp.c:319:5: note: e is assigned 'or?or:q' here. Embperl-2.5.0/epcomp.c:320:30: note: Invalid argument Explanation: The new symbolic `+`/`-` propagation adds a false positive here. In the loop, `eq = or + 1` and then the next iteration recomputes `or = strchr(eq + 1, '|')` and `e = or ? or : q`. So `e` never equals the old `or`. When the new `or` is non-null it lies at or after `eq + 1`, making `e - eq >= 1`. Cppcheck mixes the old symbolic `or` (from `eq = or + 1`) with the new one and concludes that `e - eq == -1`. The invalidFunctionArg warning on `strncasecmp` is therefore spurious. ---- 20 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libe/libesedb/libesedb_20240420.orig.tar.gz Result: your libesedb-20240420/libuna/libuna_codepage_windows_932.c:4361:42: style: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true [knownConditionTrueFalse] libesedb-20240420/libuna/libuna_codepage_windows_932.c:4339:29: note: Assuming that condition 'safe_byte_stream_index>=byte_stream_size' is not redundant libesedb-20240420/libuna/libuna_codepage_windows_932.c:4361:42: note: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true Explanation: Line 4339 returns when `safe_byte_stream_index >= byte_stream_size`, so at line 4361 we know `safe_byte_stream_index < byte_stream_size`. That makes `safe_byte_stream_index + 1 <= byte_stream_size` always true, and `index < size` rules out overflow. The new symbolic +/- constant propagation lets Cppcheck derive this. The warning is a true positive and points at a real off-by-one: the check should probably be `< byte_stream_size`. As written, `byte_stream[index+1]` can read one past the end. ---- 21 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libe/libesedb/libesedb_20240420.orig.tar.gz Result: your libesedb-20240420/libuna/libuna_codepage_windows_949.c:7379:42: style: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true [knownConditionTrueFalse] libesedb-20240420/libuna/libuna_codepage_windows_949.c:7362:29: note: Assuming that condition 'safe_byte_stream_index>=byte_stream_size' is not redundant libesedb-20240420/libuna/libuna_codepage_windows_949.c:7379:42: note: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true Explanation: Line 7362 returns early when `safe_byte_stream_index >= byte_stream_size`, so afterwards `safe_byte_stream_index < byte_stream_size`. Because the index is strictly less than the size, adding 1 cannot overflow, and `safe_byte_stream_index + 1 <= byte_stream_size` is always true. The warning is therefore correct. It also points at a real bug: the check should be `<`, otherwise `byte_stream[safe_byte_stream_index]` can be read out of bounds after the increment. The new symbolic +/- propagation lets Cppcheck find this true positive. ---- 22 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libe/libesedb/libesedb_20240420.orig.tar.gz Result: your libesedb-20240420/libuna/libuna_codepage_windows_950.c:5482:42: style: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true [knownConditionTrueFalse] libesedb-20240420/libuna/libuna_codepage_windows_950.c:5465:29: note: Assuming that condition 'safe_byte_stream_index>=byte_stream_size' is not redundant libesedb-20240420/libuna/libuna_codepage_windows_950.c:5482:42: note: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true Explanation: After the early return at line 5465, `safe_byte_stream_index < byte_stream_size` holds. So `(safe_byte_stream_index + 1) <= byte_stream_size` at line 5482 is always true, and the index is below the size, so the +1 cannot overflow. The PR adds symbolic values for `x + c`, which lets Cppcheck derive this. The warning is a true positive. It also points to a real bug: the check should be `<`, otherwise `byte_stream[safe_byte_stream_index]` after the `+= 1` can read one past the end. ---- 23 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libi/libics/libics_1.7.0.orig.tar.gz Result: your libics-1.7.0/libics_util.c:190:5: style: Variable 'ext' is assigned an expression that holds the same value. [redundantAssignment] libics-1.7.0/libics_util.c:185:9: note: ext is assigned 'str+len-(sizeof(ICSEXT)-1)' here. libics-1.7.0/libics_util.c:186:20: note: Assuming condition is false libics-1.7.0/libics_util.c:190:5: note: Variable 'ext' is assigned an expression that holds the same value. Explanation: ICSEXT and IDSEXT are different extension macros (".ics" and ".ids"). They happen to have the same length, so `str + len - (sizeof(X) - 1)` evaluates to the same address both times. The code deliberately recomputes `ext` for each extension, and each computation depends on its own macro. Calling the second assignment redundant relies on a coincidence of string lengths and is not actionable; removing it would make the code fragile. The new symbolic +/- offset propagation from the PR introduced this noisy style warning, which is in practice a false positive. ---- 24 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libm/libmsiecf/libmsiecf_20240425.orig.tar.gz Result: your libmsiecf-20240425/libuna/libuna_codepage_windows_932.c:4361:42: style: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true [knownConditionTrueFalse] libmsiecf-20240425/libuna/libuna_codepage_windows_932.c:4339:29: note: Assuming that condition 'safe_byte_stream_index>=byte_stream_size' is not redundant libmsiecf-20240425/libuna/libuna_codepage_windows_932.c:4361:42: note: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true Explanation: The early return at line 4339 guarantees `safe_byte_stream_index < byte_stream_size` from then on. The index is not changed before line 4361. So `safe_byte_stream_index + 1 <= byte_stream_size` is always true, and since the index is below the size, `+1` cannot overflow. The new symbolic +/- constant valueflow is what lets Cppcheck see this. The warning is a true positive and points at a real off-by-one bug: the check should be `<`. As written, `byte_stream[index+1]` can be read one past the end of the buffer. ---- 25 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libm/libmsiecf/libmsiecf_20240425.orig.tar.gz Result: your libmsiecf-20240425/libuna/libuna_codepage_windows_949.c:7379:42: style: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true [knownConditionTrueFalse] libmsiecf-20240425/libuna/libuna_codepage_windows_949.c:7362:29: note: Assuming that condition 'safe_byte_stream_index>=byte_stream_size' is not redundant libmsiecf-20240425/libuna/libuna_codepage_windows_949.c:7379:42: note: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true Explanation: Line 7362 returns early when safe_byte_stream_index >= byte_stream_size. So at line 7379, safe_byte_stream_index < byte_stream_size holds, and therefore safe_byte_stream_index + 1 <= byte_stream_size is always true. The index is less than a size_t value, so adding 1 cannot overflow. The new symbolic +constant value lets Cppcheck derive this, making the warning a true positive. It also points at a real bug: the check should be `<` so that byte_stream[safe_byte_stream_index] after the increment does not read one past the end. ---- 26 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libm/libmsiecf/libmsiecf_20240425.orig.tar.gz Result: your libmsiecf-20240425/libuna/libuna_codepage_windows_950.c:5482:42: style: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true [knownConditionTrueFalse] libmsiecf-20240425/libuna/libuna_codepage_windows_950.c:5465:29: note: Assuming that condition 'safe_byte_stream_index>=byte_stream_size' is not redundant libmsiecf-20240425/libuna/libuna_codepage_windows_950.c:5482:42: note: Condition '(safe_byte_stream_index+1)<=byte_stream_size' is always true Explanation: After the early return at line 5465, `safe_byte_stream_index < byte_stream_size` holds. So `safe_byte_stream_index + 1 <= byte_stream_size` is indeed always true; the `+1` cannot overflow because index < size. The new symbolic `+constant` value propagation lets Cppcheck see this. The warning is a true positive and points at a real bug: the check should be `+1 < byte_stream_size`. As written, `byte_stream[safe_byte_stream_index]` after the increment can read one byte past the end. ---- 27 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libu/libunibreak/libunibreak_8.0.orig.tar.gz Result: your adah1972-libunibreak-28a2756/tools/linebreak_test.c:165:15: style: Condition 'j>=argc' is always false [knownConditionTrueFalse] adah1972-libunibreak-28a2756/tools/linebreak_test.c:156:18: note: Assuming that condition 'i+1=argc' is always false Explanation: The loop runs only while `i + 1 < argc`, and `i` does not change before `j = i + 1`. So inside the body `j >= argc` can never be true, and the 'Option value missing' branch is dead code. The PR's new symbolic value for `i+1` lets Cppcheck see this, which adds a true positive. Both comparisons convert `argc` the same way (size_t vs int), so the signedness does not change the result. ---- 28 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mkvtoolnix/mkvtoolnix_102.0.orig.tar.xz Result: main mkvtoolnix-102.0/lib/avilib-0.6.10/avilib.c:182:15: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: In long2str(), `n` is a signed int32_t that is right-shifted and masked with 0xff to write little-endian bytes. Main warned because value flow gave `n` a negative value, presumably passed in by some caller. The callers are not shown. The PR adds symbolic values for `+`/`-` expressions and changes invalidFree. Nothing in it obviously means `n` can no longer be negative here, so losing the warnings on lines 182–184 may be a side effect: more values in the value lists may have displaced or blocked the negative argument. Right-shifting a negative value is implementation-defined, not undefined, and the result is masked. So even if the warning was correct, it was of limited value. Without the call sites that supply the negative value, it is impossible to tell whether a true positive was lost or a false positive was removed. ---- 29 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mkvtoolnix/mkvtoolnix_102.0.orig.tar.xz Result: main mkvtoolnix-102.0/lib/avilib-0.6.10/avilib.c:183:15: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: `long2str` right-shifts a signed `int32_t n`. Main's warning means some caller passed a negative value into `n`, but the call site is not shown. The PR only adds symbolic values to `+`/`-` expressions (for the invalidFree delete-with-offset case) and has nothing to do with shift checks. So this disappearance looks like a side effect on value propagation at an unseen call site. It is not clearly a fix. The original warning was also borderline: right-shifting a negative value is implementation-defined, not undefined. Without the caller, it cannot be decided whether a real negative value is no longer tracked or a bogus one was dropped. ---- 30 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mkvtoolnix/mkvtoolnix_102.0.orig.tar.xz Result: main mkvtoolnix-102.0/lib/avilib-0.6.10/avilib.c:184:15: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: `long2str` right-shifts a signed `int32_t n`. If the callers pass negative values (for example -1 header fields through the OUTLONG macro), then `n>>24` on a negative value is a real, implementation-defined portability concern. That is exactly what shiftNegativeLHS reports in the portability category, although the message wrongly calls it undefined. The PR only adds symbolic +/- values and skips invalidFree when the pointer is a known symbolic offset from `new`. None of that should change whether a negative value reaches `n`. All three shift warnings vanishing together therefore looks like a side effect, probably the extra symbolic values displacing or limiting the propagated negative value, not better understanding of the code. The call sites are not shown, so confidence is low. ---- 31 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/netradiant/netradiant_1.5.0+git20260429+dfsg.orig.tar.xz Result: your netradiant-1.5.0+git20260429/tools/quake2/extra/qe4/win_ent.c:898:2: style: Variable 'w' is assigned an expression that holds the same value. [redundantAssignment] netradiant-1.5.0+git20260429/tools/quake2/extra/qe4/win_ent.c:861:4: note: w is assigned 'iWidth-(2*5)' here. netradiant-1.5.0+git20260429/tools/quake2/extra/qe4/win_ent.c:898:2: note: Variable 'w' is assigned an expression that holds the same value. Explanation: Line 861 sets `w = iWidth - (2 * DlgXBorder)`. Line 898 assigns exactly the same expression again. Between the two lines, `w` is only read, as an argument to MOVE (a window-move macro), and `iWidth` and `DlgXBorder` are not changed. So `w` really does already hold that value, and the second assignment is redundant. The PR's new symbolic tracking of `+`/`-` with constants lets Cppcheck see this, so the new warning is a true positive, if a low-impact style one. ---- 32 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/n/nfs-utils/nfs-utils_3.1.1.orig.tar.xz Result: your nfs-utils-3.1.1/systemd/nfsroot-generator.c:111:36: error: Invalid strndup() argument nr 2. The value is -1 but the valid values are '0:'. [invalidFunctionArg] nfs-utils-3.1.1/systemd/nfsroot-generator.c:104:9: note: colon is assigned 'strchr(ip,':')' here. nfs-utils-3.1.1/systemd/nfsroot-generator.c:105:13: note: Assuming condition is false nfs-utils-3.1.1/systemd/nfsroot-generator.c:107:6: note: ip is assigned 'colon+1' here. nfs-utils-3.1.1/systemd/nfsroot-generator.c:108:9: note: colon is assigned 'strchr(ip,':')' here. nfs-utils-3.1.1/systemd/nfsroot-generator.c:109:13: note: Assuming condition is false nfs-utils-3.1.1/systemd/nfsroot-generator.c:111:36: note: Invalid argument Explanation: `ip` is set to `colon + 1`, and then `colon` is reassigned to `strchr(ip, ':')`. That new `colon` always points at or after `ip`, so `colon - ip >= 0`. The new symbolic +/- propagation keeps the stale relation `ip == colon + 1` after `colon` is reassigned, so it wrongly computes `colon - ip` as -1. The new invalidFunctionArg warning for strndup() is a false positive. ---- 33 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/openblas/openblas_0.3.34+ds.orig.tar.xz Result: your OpenMathLib-OpenBLAS-e016600/ctest/c_cblat1c.c:533:6: style: Variable 'i__1' is assigned an expression that holds the same value. [redundantAssignment] OpenMathLib-OpenBLAS-e016600/ctest/c_cblat1c.c:530:11: note: i__1 is assigned 'i__-1' here. OpenMathLib-OpenBLAS-e016600/ctest/c_cblat1c.c:533:6: note: Variable 'i__1' is assigned an expression that holds the same value. Explanation: Line 530 sets `i__1 = i__ - 1`. Lines 531-532 only assign `i__2` and write to `mwpct[i__1]` and read `cx[i__2]`. Neither `i__` nor `i__1` changes before line 533. So line 533 assigns `i__1` the value it already holds, and the redundantAssignment warning is technically correct. The new symbolic +/- offset tracking lets Cppcheck see this. The code is f2c-generated and the warning is low-value noise, but it is a true positive, not a false one. ---- 34 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/openblas/openblas_0.3.34+ds.orig.tar.xz Result: your OpenMathLib-OpenBLAS-e016600/ctest/c_cblat1c.c:767:3: style: Variable 'i__2' is assigned an expression that holds the same value. [redundantAssignment] OpenMathLib-OpenBLAS-e016600/ctest/c_cblat1c.c:764:8: note: i__2 is assigned 'i__-1' here. OpenMathLib-OpenBLAS-e016600/ctest/c_cblat1c.c:767:3: note: Variable 'i__2' is assigned an expression that holds the same value. Explanation: Line 764 sets `i__2 = i__ - 1`. Line 765 only reads `i__2` and writes array elements and `i__1`. Nothing changes `i__` before line 767, which sets `i__2 = i__ - 1` again. So line 767 stores the value `i__2` already holds, and the warning is a correct redundantAssignment finding. The PR adds symbolic values for `x + c` and `x - c`, which lets Cppcheck see that both sides are the same `i__ - 1` expression. The code is f2c-generated, so users may not care much, but the finding itself is valid. ---- 35 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/openblas/openblas_0.3.34+ds.orig.tar.xz Result: your OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:448:6: style: Variable 'i__1' is assigned an expression that holds the same value. [redundantAssignment] OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:446:11: note: i__1 is assigned 'i__-1' here. OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:448:6: note: Variable 'i__1' is assigned an expression that holds the same value. Explanation: Line 446 sets `i__1 = i__ - 1;`. Line 447 only uses `i__1` as an array index into `mwpct`, and changes neither `i__1` nor `i__`. Line 448 then assigns `i__ - 1` to `i__1` again, so the second assignment really does store the value the variable already holds. The PR now gives the `+`/`-` expression a symbolic value, which lets Cppcheck see this. The new redundantAssignment warning is correct, a true positive. It is low-value noise in f2c-generated code, but it is not wrong. ---- 36 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/openblas/openblas_0.3.34+ds.orig.tar.xz Result: your OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:474:6: style: Variable 'i__2' is assigned an expression that holds the same value. [redundantAssignment] OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:471:11: note: i__2 is assigned 'i__-1' here. OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:474:6: note: Variable 'i__2' is assigned an expression that holds the same value. Explanation: Line 471 sets `i__2 = i__ - 1`. Lines 472–473 only read `i__2` and `cx`, and assign `i__1`. Neither `i__` nor `i__2` changes before line 474. So `i__2 = i__ - 1` on line 474 stores the value `i__2` already holds, and the redundantAssignment warning is a true positive. It comes from the PR's new symbolic values for `x + c` / `x - c`, which let Cppcheck see that both expressions equal `i__-1`. The code is f2c-generated, so the warning may be of little practical use, but it is correct. ---- 37 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/openblas/openblas_0.3.34+ds.orig.tar.xz Result: your OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:488:6: style: Variable 'i__2' is assigned an expression that holds the same value. [redundantAssignment] OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:484:11: note: i__2 is assigned 'i__-1' here. OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:488:6: note: Variable 'i__2' is assigned an expression that holds the same value. Explanation: Line 484 sets `i__2 = i__ - 1`. Line 485 only reads `i__2` (`cx[i__2]`), lines 486–487 write other variables, and `i__` is unchanged in between. So at line 488 `i__2` already equals `i__ - 1`, and the reassignment really is redundant. The PR adds a symbolic value for `x - constant`, which lets Cppcheck see this. The new warning is a true positive, even though the code is f2c-generated and the redundancy is harmless. ---- 38 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/openblas/openblas_0.3.34+ds.orig.tar.xz Result: your OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:622:3: style: Variable 'i__1' is assigned an expression that holds the same value. [redundantAssignment] OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:619:8: note: i__1 is assigned 'i__-1' here. OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:622:3: note: Variable 'i__1' is assigned an expression that holds the same value. Explanation: Line 619 sets `i__1 = i__ - 1`. Between 619 and 622, `i__` and `i__1` are not modified: `i__1` is only used as an array index on line 621. So line 622 assigns `i__1` the same value it already holds, and the warning is correct. It appears because the PR now gives `i__ - 1` a symbolic value. The code is f2c-generated, so users may see it as noise, but the redundancy is real. This makes it a new true positive. ---- 39 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/openblas/openblas_0.3.34+ds.orig.tar.xz Result: your OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:623:3: style: Variable 'i__2' is assigned an expression that holds the same value. [redundantAssignment] OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:620:8: note: i__2 is assigned 'i__-1' here. OpenMathLib-OpenBLAS-e016600/ctest/c_zblat1c.c:623:3: note: Variable 'i__2' is assigned an expression that holds the same value. Explanation: Line 620 sets `i__2 = i__ - 1`. Line 621 only reads `i__2` and `i__` and writes into elements of `cx`, so neither variable changes. Line 623 then assigns `i__ - 1` to `i__2` again, which is exactly the value it already holds. The new symbolic tracking of `x - constant` lets Cppcheck see this. The warning is factually correct, though it is low-value noise in f2c-generated code. ---- 40 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/openblas/openblas_0.3.34+ds.orig.tar.xz Result: your OpenMathLib-OpenBLAS-e016600/ctest/c_zblat3c_3m.c:632:2: style: Variable 'i__3' is assigned an expression that holds the same value. [redundantAssignment] OpenMathLib-OpenBLAS-e016600/ctest/c_zblat3c_3m.c:629:7: note: i__3 is assigned 'n-j+1' here. OpenMathLib-OpenBLAS-e016600/ctest/c_zblat3c_3m.c:632:2: note: Variable 'i__3' is assigned an expression that holds the same value. Explanation: Line 629 sets `i__3 = n - j + 1`. Line 632 assigns the same expression again within the same loop iteration. In between, neither `n` nor `j` changes: line 630 only writes into the `ab` array and line 631 only reassigns `i__2`. So `i__3` already holds that value and the second assignment is truly redundant. The new symbolic +/- constant propagation lets Cppcheck see this, so this is a correct new warning. It is in f2c-generated code, which makes it of limited practical value, but it is not a false positive. ---- 41 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/pmix/pmix_7.0.0~rc1.orig.tar.gz Result: your pmix-7.0.0~rc1/src/class/pmix_bitmap.c:151:22: style: Condition 'new_size>bm->max_size' is always false [knownConditionTrueFalse] pmix-7.0.0~rc1/src/class/pmix_bitmap.c:140:15: note: Assuming that condition 'index>=bm->max_size' is not redundant pmix-7.0.0~rc1/src/class/pmix_bitmap.c:144:15: note: Assuming condition is true pmix-7.0.0~rc1/src/class/pmix_bitmap.c:150:26: note: Assignment 'new_size=index+1', assigned value is less than symbolic=bm->max_size+1 pmix-7.0.0~rc1/src/class/pmix_bitmap.c:151:22: note: Condition 'new_size>bm->max_size' is always false Explanation: The early return at line 140 guarantees index < bm->max_size. So new_size = index + 1 is at most bm->max_size, and the check `new_size > bm->max_size` at line 151 can never be true. The code comment even says the earlier check makes this clamp unnecessary. The PR's new symbolic tracking for +/- with a constant now finds this. The warning is a correct new true positive about redundant code. ---- 42 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/q/qatzip/qatzip_2.0.0.orig.tar.xz Result: your qatzip-2.0.0/src/qatzip_utils.c:2236:23: style: Variable 'ring->prod.head' is assigned an expression that holds the same value. [redundantAssignment] qatzip-2.0.0/src/qatzip_utils.c:2229:19: note: *new_head is assigned '*old_head+1' here. qatzip-2.0.0/src/qatzip_utils.c:2232:15: note: Assuming condition is false qatzip-2.0.0/src/qatzip_utils.c:2235:13: note: Assuming condition is true qatzip-2.0.0/src/qatzip_utils.c:2236:23: note: Variable 'ring->prod.head' is assigned an expression that holds the same value. Explanation: The code does `*old_head = ring->prod.head; *new_head = *old_head + 1; ring->prod.head = *new_head;`. This increments `prod.head` by one, so the new value differs from the old one and the assignment is not redundant. The PR now gives the `+` token a symbolic value with a non-zero offset (`prod.head + 1`). The redundant-assignment check apparently treats any symbolic value pointing to the same expression as 'same value' and ignores the offset. The new warning is a false positive, and the same happens for `cons.head` at line 2278. ---- 43 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/q/qatzip/qatzip_2.0.0.orig.tar.xz Result: your qatzip-2.0.0/src/qatzip_utils.c:2278:23: style: Variable 'ring->cons.head' is assigned an expression that holds the same value. [redundantAssignment] qatzip-2.0.0/src/qatzip_utils.c:2276:19: note: *new_head is assigned '*old_head+1' here. qatzip-2.0.0/src/qatzip_utils.c:2277:13: note: Assuming condition is true qatzip-2.0.0/src/qatzip_utils.c:2278:23: note: Variable 'ring->cons.head' is assigned an expression that holds the same value. Explanation: `*old_head` is read from `ring->cons.head`, `*new_head` is set to `*old_head + 1`, and then `ring->cons.head = *new_head` stores the incremented value. The variable changes by 1, so the assignment is not redundant and the warning is a false positive. It comes from the PR's new symbolic offset values: `*old_head+1` now gets the symbolic value `ring->cons.head + 1`. The redundantAssignment check then seems to treat that symbolic value as equal to `ring->cons.head` without looking at the offset. ---- 44 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/stella/stella_7.0+dfsg.orig.tar.xz Result: your stella-7.0/src/debugger/gui/PromptWidget.cxx:460:24: style: Condition '_currentPos+1<=_promptEndPos' is always true [knownConditionTrueFalse] stella-7.0/src/debugger/gui/PromptWidget.cxx:456:20: note: Assuming that condition '_currentPos>=_promptEndPos' is not redundant stella-7.0/src/debugger/gui/PromptWidget.cxx:460:24: note: Condition '_currentPos+1<=_promptEndPos' is always true Explanation: After the early return at line 456, `_currentPos < _promptEndPos` holds for these integer members. Nothing between lines 456 and 460 modifies them, so `_currentPos + 1 <= _promptEndPos` really is always true; overflow would be UB anyway. The PR's new symbolic tracking of `x + constant` lets Cppcheck see this redundant check. This is a new true positive. ---- 45 / 50 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/stella/stella_7.0+dfsg.orig.tar.xz Result: your stella-7.0/src/debugger/gui/RiotWidget.cxx:137:3: style: Variable 'xpos' is assigned an expression that holds the same value. [redundantAssignment] stella-7.0/src/debugger/gui/RiotWidget.cxx:125:3: note: xpos is assigned 'hBorder+lwidth' here. stella-7.0/src/debugger/gui/RiotWidget.cxx:137:3: note: Variable 'xpos' is assigned an expression that holds the same value. Explanation: Line 125 sets `xpos` to `hBorder` and then expands the `CREATE_IO_REGS` macro, which presumably advances `xpos` by a fixed amount. The PR now carries symbolic values through `+`/`-` with a constant, so Cppcheck can tell the result equals `hBorder+lwidth`. Nothing between line 125 and line 137 writes `xpos`: the loop only uses `hBorder`. So `xpos = hBorder + lwidth;` at line 137 reassigns the same value, which matches the note. This mirrors the equally new warning at line 162, which is clearly correct because `xpos` is untouched between lines 137 and 162. The macro body is not shown, so I cannot confirm that its increment equals `lwidth`; hence low confidence. ---- 46 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/stella/stella_7.0+dfsg.orig.tar.xz Result: your stella-7.0/src/debugger/gui/RiotWidget.cxx:162:3: style: Variable 'xpos' is assigned an expression that holds the same value. [redundantAssignment] stella-7.0/src/debugger/gui/RiotWidget.cxx:137:8: note: xpos is assigned 'hBorder+lwidth' here. stella-7.0/src/debugger/gui/RiotWidget.cxx:162:3: note: Variable 'xpos' is assigned an expression that holds the same value. Explanation: Line 137 sets `xpos = hBorder + lwidth`. Lines 138–161 only read `xpos` and never change it, nor do they change `hBorder` or `lwidth`. Line 162 then assigns the same expression again, so it really is redundant. The PR's new symbolic values for `+`/`-` with a constant let Cppcheck see that both assignments give the same value. This is a correct, if low-severity, style finding: a new true positive. ---- 47 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/texstudio/texstudio_4.9.7+ds.orig.tar.xz Result: your texstudio-4.9.7+ds/src/latexoutputfilter.cpp:477:39: error: Out of bounds access in expression 'strLine[i+1]' [containerOutOfBounds] texstudio-4.9.7+ds/src/latexoutputfilter.cpp:461:20: note: Assuming that condition 'i=end' is always false [knownConditionTrueFalse] linux-msm-tqftpserv-a9a05e3/tqftpserv.c:238:12: note: end is assigned 'buf+sizeof(buf)' here. linux-msm-tqftpserv-a9a05e3/tqftpserv.c:239:12: note: Assignment 'p=buf', assigned value is symbolic=end-512 linux-msm-tqftpserv-a9a05e3/tqftpserv.c:242:3: note: p is incremented', new value is symbolic=end-511 linux-msm-tqftpserv-a9a05e3/tqftpserv.c:243:3: note: p is incremented', new value is symbolic=end-510 linux-msm-tqftpserv-a9a05e3/tqftpserv.c:245:6: note: Assuming condition is true linux-msm-tqftpserv-a9a05e3/tqftpserv.c:246:13: note: Condition 'p+8>=end' is always false Explanation: `buf` is a local `char[512]`, `end = buf + 512` and `p = buf`. After two `*p++`, `p` is `buf + 2`, so `p + 8 >= end` means `buf + 10 >= buf + 512`, which is always false. The PR adds symbolic values for `p + constant`, which lets Cppcheck evaluate this check. The warning is correct and the notes trace the reasoning accurately. The check is defensive code that cannot trigger at this point, so it is a valid true positive, though some users may see it as low value. ---- 49 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/transcend/transcend_0.3.dfsg2.orig.tar.gz Result: your transcend-0.3+dfsg2.orig/Transcend/editors/ObjectControlPointEditor.cpp:745:30: style: Variable 'mControlPoint->mNumTriangleVertices' is assigned an expression that holds the same value. [redundantAssignment] transcend-0.3+dfsg2.orig/Transcend/editors/ObjectControlPointEditor.cpp:705:36: note: newNumVertices is assigned 'oldNumVertices+3' here. transcend-0.3+dfsg2.orig/Transcend/editors/ObjectControlPointEditor.cpp:745:30: note: Variable 'mControlPoint->mNumTriangleVertices' is assigned an expression that holds the same value. Explanation: newNumVertices is oldNumVertices + 3, where oldNumVertices was read from mControlPoint->mNumTriangleVertices. Assigning it back changes the member by 3, so the assignment is not redundant. The PR adds symbolic values with a non-zero offset for +/- expressions. The redundantAssignment check apparently treats any symbolic value of the target as 'same value' and ignores the offset. This is a new false positive. ---- 50 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/u/uacme/uacme_1.8.1.orig.tar.gz Result: your uacme-1.8.1/libev/ev.c:2615:23: style: Condition 'pos+3