AI review of 2026-10-09_14-44-28-cc643ff72ecf-results.txt PR: #8819 https://github.com/cppcheck-opensource/cppcheck/pull/8819 Tested: cc643ff72ecf9b6274de9f1320b47f2ac4e48d77 Merge base: 746b3a7c03201ced453ab8ea06c2ce0ae35b140d Reviewed: 2026-10-10 14:54:56 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 113 in the report (random sample), 2 not reviewed: valueFlowMaxIterations Verdicts: 26 improvement, 2 neutral, 20 regression, 2 unclear Tokens: 125899 input, 382928 cache read, 95732 cache write, 43055 output The verdicts are written by AI and can be wrong. ---- 1 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/abyss/abyss_2.3.10.orig.tar.xz Result: main abyss-2.3.10/dialign/prob.c:120:15: style: Condition '(scr-j)<=omxscr' is always true [knownConditionTrueFalse] abyss-2.3.10/dialign/prob.c:114:15: note: Assignment 'scr=0', assigned value is 0 abyss-2.3.10/dialign/prob.c:120:15: note: Condition '(scr-j)<=omxscr' is always true Explanation: `scr` is `long` and `j` is `unsigned long`, so `scr-j` is computed as `unsigned long`. When `j > scr` (for example `scr=0`, `j=1`), the subtraction wraps to a huge value that is greater than `omxscr`, and the condition is false. The check exists exactly to guard against that wrap. So '(scr-j)<=omxscr is always true' was a false positive. The PR stops propagating impossible bounds through unsigned arithmetic that can wrap, which removes this false positive. ---- 2 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/bcg729/bcg729_1.1.2.orig.tar.gz Result: main bcg729-1.1.2/src/g729FixedPointMath.h:116:9: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: `integer = SHR16(x,11)` is negative for any negative 16-bit `x`, and the early returns only rule out values below -15. So `integer` can be in [-15,-1] when `SHL16(integer,11)` runs, and left-shifting a negative signed value is undefined behaviour in C. The removed shiftNegativeLHS warning was therefore a true positive. The PR made `getValueLE` ignore values with Bound::Lower. A lower-bound value such as -15 (meaning `integer >= -15`) still says -15 itself is reachable, so ignoring it hides a real negative value. The warning column points at the outer SHL16, whose argument is non-negative; this most likely reflects macro-expansion location mapping rather than a different finding. ---- 3 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-h8300-hms/binutils-h8300-hms_2.16.1.orig.tar.gz Result: main binutils-h8300-hms-2.16.1/gas/config/tc-z8k.c:1481:40: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: The PR removed a shiftNegativeLHS warning at tc-z8k.c:1481:40. The marked line is only the message string `_("relative call out of range")` and contains no left shift. The nearby shift `val >> 8` is a right shift, which shiftNegativeLHS does not check. The warning probably comes from a macro expansion or a line-mapping offset, so the shifted expression cannot be identified from the code shown. The PR change behind the removal (getValueLE now ignores lower-bound values) can remove both real and false findings. Without the actual expression, it is not possible to tell whether the removed warning was a true or false positive. ---- 4 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-riscv64-unknown-elf/binutils-riscv64-unknown-elf_2.32.2020.04+dfsg.orig.tar.gz Result: main binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/gas/config/tc-s12z.c:493:16: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: The only shifts near this location are `0x1u << 17` on lines 492 and 494. The left operand is an unsigned literal with value 1, so shifting a negative value is impossible and the old shiftNegativeLHS warning was a false positive. The PR changes how impossible bounds and cast ranges propagate through unsigned arithmetic and casts. That plausibly removes the bogus negative value main had derived, along with similar shiftNegativeLHS removals elsewhere in this package. ---- 5 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-riscv64-unknown-elf/binutils-riscv64-unknown-elf_2.32.2020.04+dfsg.orig.tar.gz Result: main binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/gas/config/tc-z8k.c:1508:40: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: The reported location (line 1508, column 40) is inside the `_("relative call out of range")` message macro, and no left shift is visible there. The only nearby shift is `(val >> 8)` on line 1510, which is a right shift, and this check is about left shifts. So the expression that triggered the warning cannot be identified from the shown code. The PR stops getValueLE from using Lower-bound values, which probably removes false shiftNegativeLHS warnings, consistent with several similar removals in this package. Still, without seeing the shifted operand, I cannot tell whether this warning was a true or false positive. ---- 6 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-riscv64-unknown-elf/binutils-riscv64-unknown-elf_2.32.2020.04+dfsg.orig.tar.gz Result: main binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/opcodes/v850-opc.c:160:21: style: Condition 'ret>32' is always false [knownConditionTrueFalse] binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/opcodes/v850-opc.c:157:12: note: Assignment 'ret=32-(ret*2)', assigned value is less than 33 binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/opcodes/v850-opc.c:159:15: note: Assuming condition is true binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/opcodes/v850-opc.c:160:21: note: Condition 'ret>32' is always false Explanation: In extract_i5div3, `ret = (insn & 0x003c0000) >> 18` is in the range 0..15. So `ret * 2` is at most 30, and `32 - (ret*2)` is in 2..32 with no unsigned wrap-around. The condition `ret > 32` is therefore genuinely always false, and the main warning was a true positive. The PR now drops impossible bounds on any arithmetic with an unsigned long result to avoid wrap-around false positives. That also loses this correct inference, where wrap-around cannot happen. A valid diagnostic was removed. ---- 7 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/cc65/cc65_2.19.orig.tar.gz Result: main cc65-2.19/test/val/add3.c:238:6: style: Condition 'ulong0' is always true [knownConditionTrueFalse] cc65-2.19/test/val/add3.c:211:19: note: Assignment 'ulong0=ulong0+0xff', assigned value is greater than 254 cc65-2.19/test/val/add3.c:216:19: note: Assignment 'ulong0=ulong0+0x100', assigned value is greater than 510 cc65-2.19/test/val/add3.c:220:19: note: Assignment 'ulong0=ulong0+0xfe00', assigned value is greater than 65534 cc65-2.19/test/val/add3.c:224:19: note: Assignment 'ulong0=ulong0+0xff0000', assigned value is greater than 16777214 cc65-2.19/test/val/add3.c:228:19: note: Assignment 'ulong0=ulong0+0x7e000000', assigned value is greater than 2130706430 cc65-2.19/test/val/add3.c:232:19: note: Assignment 'ulong0=ulong0+0x2000000', assigned value is greater than 2164260862 cc65-2.19/test/val/add3.c:237:19: note: Assignment 'ulong0=ulong0+0x7f000000', assigned value is greater than 4294967294 cc65-2.19/test/val/add3.c:238:6: note: Condition 'ulong0' is always true Explanation: `ulong0` is a global `unsigned long`, and line 237 deliberately wraps it around to zero (as on cc65's 32-bit long). Cppcheck cannot know the value of the global, and unsigned addition can wrap. So the claim that 'ulong0' is always true at line 238 is a false positive in both versions. The PR only changes the explanation: the long chain of 'greater than' notes is replaced by a single note ('greater than 2130706431' after adding 0x7f000000). That note still ignores wrap-around. The same false positive is reported either way, so nothing meaningfully changes for users. ---- 8 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/c/cc65/cc65_2.19.orig.tar.gz Result: your cc65-2.19/test/val/add3.c:238:6: style: Condition 'ulong0' is always true [knownConditionTrueFalse] cc65-2.19/test/val/add3.c:237:19: note: Assignment 'ulong0=ulong0+0x7f000000', assigned value is greater than 2130706431 cc65-2.19/test/val/add3.c:238:6: note: Condition 'ulong0' is always true Explanation: The same knownConditionTrueFalse warning at line 238 is still reported; only the supporting note changed. Main derived a chain of lower bounds through every addition, ending at 'greater than 4294967294'. The PR drops impossible bounds through unsigned arithmetic, so only the last step remains: 'greater than 2130706431', presumably from ulong0 >= 0 plus 0x7f000000. That step still ignores wrap-around. With a 64-bit unsigned long (Debian host platform), ulong0 is 0x100000000 here, so 'always true' is correct on both runs, and the old note was actually more precise. On cc65's intended 32-bit long the value wraps to 0, so the warning is a false positive there in both versions. The verdict, and whether it is right, are unchanged; only the wording differs slightly, so the change has no real effect for users. ---- 9 / 50 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/c/cdo/cdo_2.6.5.orig.tar.gz Result: main cdo-2.6.5/src/cdo_getopt.cc:78:20: style: Condition 'space_left>terminal_width' is always false [knownConditionTrueFalse] cdo-2.6.5/src/cdo_getopt.cc:37:24: note: Assignment 'terminal_width=120', assigned value is 120 cdo-2.6.5/src/cdo_getopt.cc:69:33: note: Calling function 'get_width' returns 120 cdo-2.6.5/src/cdo_getopt.cc:72:22: note: Assuming condition is false cdo-2.6.5/src/cdo_getopt.cc:77:62: note: Assignment 'space_left=terminal_width-front_pad-num_spaces-sourround.size()', assigned value is less than 115 cdo-2.6.5/src/cdo_getopt.cc:78:20: note: Condition 'space_left>terminal_width' is always false Explanation: `space_left = terminal_width - 5 - sourround.size()` is evaluated in `size_t`. It can wrap around and is then truncated to `int`. The line 78 check is the author's guard against that wrap-around. Main reached 'always false' by carrying an upper bound ('less than 115') through this unsigned subtraction. It also assumed `get_width()` returns 120, although it can return `ws_col`. That reasoning is unsound: the PR stops pushing impossible bounds through unsigned +/-/* precisely because wrap-around breaks them. The condition can in fact be true, e.g. with `terminal_width` 120 and `sourround.size()` near 2^32, the truncated result is 215. So the warning is not provably correct. In realistic use the guard is nearly dead code, so some users might have found the warning useful, hence low confidence. ---- 10 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/e/edflib/edflib_1.27.orig.tar.xz Result: main edflib-1.27/edflib.c:3426:24: warning: Either the condition 'value<32' is redundant or the array 'conv_table[130]' is accessed at index -95, which is out of bounds. [negativeIndex] edflib-1.27/edflib.c:3419:14: note: Assuming that condition 'value<32' is not redundant edflib-1.27/edflib.c:3426:24: note: Negative array index Explanation: The value comes from an unsigned char, so it is in [0,255]. If value<32 the loop continues. Values from 32 to 126 also continue because of the check on line 3414. So at line 3426 the value is in [127,255] and the index value-127 is in [0,128]. That is inside conv_table[130]. The old warning about index -95 (value 32) cannot happen. It was a false positive, and removing it is an improvement. ---- 11 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/e/edflib/edflib_1.27.orig.tar.xz Result: main edflib-1.27/unittest/unittest.c:1062:28: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: In this loop `tmp = -1010000 + (i * 105300)`. At i=0, `tmp` is -1010000, so `tmp >> 8` really does shift a negative value. That is implementation-defined, and it is exactly what the portability check shiftNegativeLHS is meant to flag, so the main warning was a true positive. The PR changes `getValueLE` to ignore values with a Lower bound. The negative value of `tmp` most likely reaches the shift as such a lower bound, derived from the loop variable, so the check no longer sees it. The removal is therefore a lost true positive; the same happens at line 1064. ---- 12 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/e/edflib/edflib_1.27.orig.tar.xz Result: main edflib-1.27/unittest/unittest.c:1064:28: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: In this loop `tmp = -1010000 + (i * 105300)` for i = 0..19, so `tmp` really is negative (-1010000 at i=0, and still negative for several more iterations). The expression `(tmp >> 16)` therefore right-shifts a negative value. That is implementation-defined in C, which is exactly the portability issue shiftNegativeLHS is meant to flag. The warning was a true positive. The PR changed getValueLE to ignore values with a Lower bound and filters impossible and conditional values in arithmetic, and this apparently makes Cppcheck lose the negative value of `tmp`. The same loss removes the identical warning on line 1062. Losing a correct warning is a regression. ---- 13 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/flite/flite_2.2.orig.tar.gz Result: main flite-2.2/src/speech/g72x.c:349:16: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: In the else branch, fa1 is in [-8191, 8191]. fa1 is ±a[0], a signed coefficient, so it really can be negative, and `fa1 >> 5` really can shift a negative value. Main reported this through getValueLE(-1), using the possible value -8191 from the `fa1 < -8191` condition. The PR changes getValueLE to ignore values with Bound::Lower. A lower bound of -8191 still allows negative values, so dropping it removes a valid shiftNegativeLHS portability warning. Right-shifting a negative value is implementation-defined, but Cppcheck intentionally reports `>>` here. Losing the warning is a lost true positive, not a removed false positive. ---- 14 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/ghostscript/ghostscript_10.08.0~dfsg.orig.tar.xz Result: main ghostpdl-10.08.0/base/write_t2.c:54:72: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: At line 54, `a_int` can really be negative. The first branch handles [-107,107] and the inner branches remap [108,1131] and [-1131,-108]. The `else` path (prefix byte 28) therefore keeps raw values in [-32768,-1132], so `a_int >> 8` shifts a negative long. The warning was a genuine finding about shifting a negative value; strictly, right-shifting a negative value is implementation-defined rather than undefined, but Cppcheck deliberately reports it. The PR changes `getValueLE` to ignore values with a lower bound, and that drops this warning. The same change removes several other `shiftNegativeLHS` reports in this package. Losing a true positive is a regression. ---- 15 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/ghostscript/ghostscript_10.08.0~dfsg.orig.tar.xz Result: main ghostpdl-10.08.0/contrib/gdevcd8.c:1425:36: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: `dr` is an `int` computed from the difference of two bytes, so it can genuinely be negative. The guard `dr >= -16 && dr <= 15` keeps that range, so `dr << 10` can shift a negative value. In C that is undefined behaviour, so the shiftNegativeLHS warning was a true positive. The PR changed `getValueLE` to ignore values with `Bound::Lower`. A lower bound of -16 means `dr` can be any value from -16 upward, which still includes values <= -1. Skipping it loses this valid diagnostic. ---- 16 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/godot/godot_4.6.3+ds.orig.tar.xz Result: main godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22340:24: warning: Either the condition 'best_idx>=0' is redundant or the array 'mid_dots[15]' is accessed at index -3, which is out of bounds. [negativeIndex] godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22344:31: note: Compound assignment '=', assigned value is 1 godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22344:41: note: Assignment to 'low=mid+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22343:13: note: Assignment to 'mid=low' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22342:41: note: Assignment to 'low=mid+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22341:17: note: Assignment to 'mid=low+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22340:41: note: Assignment to 'low=mid+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22340:24: note: Negative array index Explanation: `low` starts at 0 and is only ever set to `mid + 1`, where `mid` is built from non-negative values (7, low+3, low+1, low). So `low` is always in 0..15, and `mid` at line 22340 is 3 or 11, never -3. The condition `best_idx >= 0` is on a `uint32_t` and is trivially true; it says nothing about whether `low` could be negative. The warning about `mid_dots` being accessed at index -3 was a false positive, which appears to come from impossible bounds being propagated wrongly through unsigned arithmetic. The PR stops that propagation and removes the false positive. ---- 17 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/godot/godot_4.6.3+ds.orig.tar.xz Result: main godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22342:24: warning: Either the condition 'best_idx>=0' is redundant or the array 'mid_dots[15]' is accessed at index -1, which is out of bounds. [negativeIndex] godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22344:31: note: Compound assignment '=', assigned value is 1 godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22344:41: note: Assignment to 'low=mid+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22343:13: note: Assignment to 'mid=low' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22342:41: note: Assignment to 'low=mid+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22342:24: note: Negative array index Explanation: In this binary search, low starts at 0 and only grows (low = mid + 1). mid is always low+7, low+3, low+1 or low, so it is never negative. The warning that mid_dots is accessed at index -1 is therefore a false positive. It came from the 'best_idx >= 0' check in the assert: best_idx is uint32_t, so that check is meaningless, yet Cppcheck used it to assume best_idx and low could be negative. With the PR, impossible bounds are no longer pushed through unsigned arithmetic that can wrap, and the false positive goes away. ---- 18 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/godot/godot_4.6.3+ds.orig.tar.xz Result: main godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22372:24: warning: Either the condition 'best_idx>=0' is redundant or the array 'mid_dots[15]' is accessed at index -3, which is out of bounds. [negativeIndex] godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22376:31: note: Compound assignment '=', assigned value is 1 godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22376:41: note: Assignment to 'low=mid+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22375:13: note: Assignment to 'mid=low' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22374:41: note: Assignment to 'low=mid+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22373:17: note: Assignment to 'mid=low+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22372:41: note: Assignment to 'low=mid+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22372:24: note: Negative array index Explanation: This is a binary search where `low` starts at 0 and only ever increases (`low = mid + 1` with `mid >= low`). So `mid` at line 22372 is always 3..11 and can never be -3. The `best_idx>=0` condition is in an assert on an unsigned variable (`uint32_t best_idx`), so it says nothing about a negative index. Main's negativeIndex warning was a false positive, most likely from impossible bounds being carried through unsigned arithmetic, which the PR now blocks. Removing it is an improvement. ---- 19 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/godot/godot_4.6.3+ds.orig.tar.xz Result: main godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22374:24: warning: Either the condition 'best_idx>=0' is redundant or the array 'mid_dots[15]' is accessed at index -1, which is out of bounds. [negativeIndex] godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22376:31: note: Compound assignment '=', assigned value is 1 godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22376:41: note: Assignment to 'low=mid+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22375:13: note: Assignment to 'mid=low' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22374:41: note: Assignment to 'low=mid+1' godotengine-godot-7d41c59/thirdparty/basis_universal/transcoder/basisu_transcoder.cpp:22374:24: note: Negative array index Explanation: This is a binary search where `low` starts at 0 and only ever becomes `mid+1` with `mid >= low`. So `low` never decreases, and `mid = low + 1` is at least 1. The index into `mid_dots` can never be -1, so the negativeIndex warning was a false positive. The warning referred to the condition `best_idx >= 0`, where `best_idx` is a `uint32_t`. Cppcheck seems to have derived an impossible-bound value there and pushed it backwards wrongly through the unsigned conversion and the arithmetic. The PR stops propagating impossible bounds through unsigned arithmetic, which removes this false positive. ---- 20 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/godot/godot_4.6.3+ds.orig.tar.xz Result: main godotengine-godot-7d41c59/thirdparty/ufbx/ufbx.c:2297:23: style: Condition 'num_codes_left<0' is always false [knownConditionTrueFalse] godotengine-godot-7d41c59/thirdparty/ufbx/ufbx.c:2282:24: note: Assignment 'num_codes_left=1', assigned value is 1 godotengine-godot-7d41c59/thirdparty/ufbx/ufbx.c:2301:14: note: Assuming that condition 'count>0' is not redundant godotengine-godot-7d41c59/thirdparty/ufbx/ufbx.c:2296:43: note: Assignment 'num_codes_left=(num_codes_left<<1)-(int32_t)count', assigned value is greater than 1 godotengine-godot-7d41c59/thirdparty/ufbx/ufbx.c:2297:23: note: Condition 'num_codes_left<0' is always false Explanation: `count` is a `uint32_t` read from `bits_counts[bits]`, so `(int32_t)count` can be any value, including one larger than `num_codes_left<<1`. The subtraction can therefore make `num_codes_left` negative, and the overfull-tree check `if (num_codes_left < 0) return -1;` is a meaningful guard. Main's note "assigned value is greater than 1" was wrong, so the warning that the condition is always false was a false positive. The PR changes how impossible bounds on casts and arithmetic are handled, which removed this incorrect inference. ---- 21 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/godot/godot_4.6.3+ds.orig.tar.xz Result: main godotengine-godot-7d41c59/thirdparty/ufbx/ufbx.c:2303:46: style: Condition 'num_codes_left==0' is always false [knownConditionTrueFalse] godotengine-godot-7d41c59/thirdparty/ufbx/ufbx.c:2282:24: note: Assignment 'num_codes_left=1', assigned value is 1 godotengine-godot-7d41c59/thirdparty/ufbx/ufbx.c:2301:14: note: Assuming that condition 'count>0' is not redundant godotengine-godot-7d41c59/thirdparty/ufbx/ufbx.c:2296:43: note: Assignment 'num_codes_left=(num_codes_left<<1)-(int32_t)count', assigned value is greater than 1 godotengine-godot-7d41c59/thirdparty/ufbx/ufbx.c:2301:38: note: Assuming condition is true godotengine-godot-7d41c59/thirdparty/ufbx/ufbx.c:2303:46: note: Condition 'num_codes_left==0' is always false Explanation: `num_codes_left = (num_codes_left << 1) - (int32_t)count` can easily become 0. For example, with count == 2 at bits == 1 it gives 2 - 2 = 0, which passes the `< 0` check. When count > 0 at that point, the `== 0` test on line 2303 can therefore be true. Main's claim that the value is 'greater than 1' is wrong, so its 'always false' warning was a false positive. The pull request removed it. ---- 22 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/got/got_0.126.orig.tar.gz Result: main got-portable-0.126/gotd/repo_write.c:746:17: style: Condition 'nobj_delta>0' is always false [knownConditionTrueFalse] got-portable-0.126/gotd/repo_write.c:743:17: note: Assuming that condition 'nobj_total>0' is not redundant got-portable-0.126/gotd/repo_write.c:741:30: note: Assignment 'nobj_delta=nobj_total-nobj_loose', assigned value is less than 1 got-portable-0.126/gotd/repo_write.c:746:17: note: Condition 'nobj_delta>0' is always false Explanation: nobj_total and nobj_loose are uint32_t, so 'nobj_total - nobj_loose' is unsigned arithmetic that can wrap. The result is converted to int nobj_delta, which is positive whenever nobj_total > nobj_loose. The old warning claimed the assigned value is less than 1 and that 'nobj_delta>0' is always false, which is wrong. It came from wrongly propagating impossible bounds through wrapping unsigned subtraction. The PR blocks exactly that propagation, so removing this false positive is correct. ---- 23 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/got/got_0.126.orig.tar.gz Result: main got-portable-0.126/gotd/repo_write.c:749:17: style: Condition 'p_resolved>0' is always false [knownConditionTrueFalse] got-portable-0.126/gotd/repo_write.c:740:34: note: Assignment 'p_resolved=0', assigned value is 0 got-portable-0.126/gotd/repo_write.c:749:17: note: Condition 'p_resolved>0' is always false Explanation: nobj_total - nobj_loose is uint32_t subtraction, so it can wrap and then be converted to int. The result may be positive, for example when nobj_total > nobj_loose. Main wrongly inferred that nobj_delta is less than 1, which made 'nobj_delta>0' look always false. Because of that, p_resolved stayed 0 on every path main considered, so 'p_resolved>0' was reported as always false. In reality p_resolved is assigned at line 747 when nobj_delta > 0, so it can be positive. The PR stops impossible bounds from propagating through unsigned arithmetic that can wrap, which removes this false positive. ---- 24 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/grpc/grpc_1.83.0.orig.tar.gz Result: main grpc-1.83.0/third_party/upb/upb/wire/decode.c:145:36: error: Signed integer overflow for expression '-(int32_t)(n&1)'. [integerOverflow] Explanation: `(int32_t)(n & 1)` can only be 0 or 1, so negating it gives 0 or -1 and can never overflow. This is the standard zigzag decode. Main reported a signed overflow here, which is a false positive. It probably came from an impossible bound being carried through the cast, e.g. treating the value as possibly INT32_MIN. The PR adds proper range bounds on casts and stops propagating impossible bounds through wrapping arithmetic, and the false positive goes away. ---- 25 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/ibus-unikey/ibus-unikey_0.7.0~beta1.orig.tar.gz Result: main ibus-unikey-0.7.0~beta1/ukengine/ukengine.cpp:1034:76: warning: Either the condition 'm_current<0' is redundant or the array 'm_buffer[128]' is accessed at index -1, which is out of bounds. [negativeIndex] ibus-unikey-0.7.0~beta1/ukengine/ukengine.cpp:1025:40: note: Assuming that condition 'm_current<0' is not redundant ibus-unikey-0.7.0~beta1/ukengine/ukengine.cpp:1034:76: note: Negative array index Explanation: Line 1025 only guarantees `m_current >= 0`. Line 1034 then reads `m_buffer[m_current-1]` without checking `m_current > 0`, so when `m_current == 0` the index is -1. Cppcheck's "condition is redundant or index -1" warning describes this correctly, and the code has no guard against it. The PR changed `getValueLE` to ignore values with a Lower bound. The value from `m_current >= 0` minus 1 is such a bound (index >= -1), and it still includes -1 exactly. Dropping it loses this valid boundary detection, so a true positive was removed. ---- 26 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/inkscape/inkscape_1.4.3.orig.tar.xz Result: main inkscape-1.4.3_2025-12-25_0d15f75042/src/ui/dialog/dialog-multipaned.cpp:1228:19: warning: Either the condition '_handle<0' is redundant, otherwise there is negative array index -1. [negativeContainerIndex] inkscape-1.4.3_2025-12-25_0d15f75042/src/ui/dialog/dialog-multipaned.cpp:1224:17: note: Assuming that condition '_handle<0' is not redundant inkscape-1.4.3_2025-12-25_0d15f75042/src/ui/dialog/dialog-multipaned.cpp:1228:19: note: Negative array index Explanation: After `if (_handle < 0) return;` the code only knows `_handle >= 0`. The warning assumes `_handle == 0`, which makes `_handle - 1 == -1`. But that value is only the lower edge of a range (bound Lower), not a value the guard implies. In this code `_handle` is the index of a drag handle, which always sits between two panels in `children`, so it is never 0. The `< 0` test only catches the -1 'no handle' sentinel. The PR's `getValueLE` change stops treating lower-bound values as concrete values, which removes this likely false positive. ---- 27 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/inkscape/inkscape_1.4.3.orig.tar.xz Result: main inkscape-1.4.3_2025-12-25_0d15f75042/src/ui/dialog/dialog-multipaned.cpp:1230:19: warning: Either the condition '_handle<0' is redundant, otherwise there is negative array index -1. [negativeContainerIndex] inkscape-1.4.3_2025-12-25_0d15f75042/src/ui/dialog/dialog-multipaned.cpp:1224:17: note: Assuming that condition '_handle<0' is not redundant inkscape-1.4.3_2025-12-25_0d15f75042/src/ui/dialog/dialog-multipaned.cpp:1230:19: note: Negative array index Explanation: The function only returns early for `_handle < 0`, then reads `children[_handle - 1]` at 1228 and 1230. If `_handle == 0`, which the guard allows, that index is -1, so the off-by-one guard is a real weakness. This is cppcheck's normal boundary heuristic: in the false branch of `_handle<0`, `_handle` is assumed ≥0 (lower-bound value 0), so `_handle-1` can be -1. The warning disappears because of the new `getValueLE` filter, which drops every value with `Bound::Lower`. A lower bound of -1 still includes -1, so the filter hides a legitimately possible negative index. The PR's unsigned-wraparound logic does not apply here: `_handle` is signed and there is no cast, so Cppcheck does not understand this code any better. In practice Inkscape probably never sets `_handle` to 0, so the warning is weak, but losing it comes from a blanket suppression, not a precise fix. ---- 28 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/libg/libgooglepinyin/libgooglepinyin_0.1.2.orig.tar.bz2 Result: main libgooglepinyin-0.1.2/src/dictbuilder.cpp:309:27: style: Condition 'move_pos-1>0' is always true [knownConditionTrueFalse] libgooglepinyin-0.1.2/src/dictbuilder.cpp:308:15: note: Assuming that condition '0==move_pos-1' is not redundant libgooglepinyin-0.1.2/src/dictbuilder.cpp:309:27: note: Condition 'move_pos-1>0' is always true Explanation: `move_pos - 1` has type size_t, so it can never be negative. In the `||` expression, the right side runs only when `0 == move_pos - 1` is false, which means `move_pos - 1 != 0`. For an unsigned value, that makes `move_pos - 1 > 0` always true, and wrap-around does not change this. The warning correctly flags a redundant sub-condition, so it was a true positive. The PR drops impossible bounds when propagating through unsigned arithmetic. That removes the knowledge that the unsigned value `move_pos-1` cannot be below 0, so the valid warning is lost. ---- 29 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libr/librandomx/librandomx_1.2.2.orig.tar.gz Result: main RandomX-1.2.2/src/jit_compiler_rv64.cpp:1077:23: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: Inside `if (offset >= -256)`, `offset` can be negative. The comment `sign bit is always 1` confirms these are backward branches, so `offset` is in fact always negative here. Right-shifting it with `offset >> 5` is implementation-defined, which is a genuine portability issue, so the warning was a true positive. The PR changes `getValueLE` to ignore values with a Lower bound. The possible value -256 that comes from the `>= -256` condition is itself reachable, yet it is now discarded. This drops a valid warning, so it is a lost true positive. ---- 30 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/meschach/meschach_1.2b.orig.tar.gz Result: main meschach-1.2b/svd.c:128:28: warning: Either the condition 'sp<0' is redundant or the array 'stack[100]' is accessed at index -1, which is out of bounds. [negativeIndex] meschach-1.2b/svd.c:126:10: note: Assuming that condition 'sp<0' is not redundant meschach-1.2b/svd.c:128:12: note: sp is decremented', new value is -1 meschach-1.2b/svd.c:128:28: note: Negative array index Explanation: Line 128 pops two values: `r = stack[sp--]; l = stack[sp--];`. The removed warning is about the second access, which reads stack[-1] only if sp is 0 after the `sp < 0` check. Every push in this function is done in pairs (`stack[++sp] = ...; stack[++sp] = ...;`), so sp is presumably initialized to -1 and stays -1 or odd. sp can then never be 0 at line 128, and the index -1 cannot happen. The removed warning is therefore a false positive. It is not clear that the PR removed it for exactly this reason; the getValueLE change that ignores Lower-bound values likely did it. Still, users lose a spurious negativeIndex warning. ---- 31 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/ncbi-tools6/ncbi-tools6_6.1.20170106+dfsg2.orig.tar.xz Result: main ncbi-tools6_6.1.20170106+dfsg2/algo/blast/core/ncbi_erf.c:172:19: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: In this exp-style routine, `k` can really be negative. For negative x, `xsb` is 1, so `k = 1-xsb-xsb` gives -1, and `(int)(invln2*x+halF[xsb])` is negative too. The guard `k >= -1021` still lets negative values through, so `k<<20` shifts a negative value. The shiftNegativeLHS portability warning was therefore a true positive. The PR's change to getValueLE now ignores values with a Lower bound. A lower-bound value such as -1021 (k >= -1021) still allows k itself to be negative, so ignoring it drops a valid warning. ---- 32 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/netcdf-parallel/netcdf-parallel_4.10.1.orig.tar.gz Result: main netcdf-c-4.10.1/ncgen/escapes.c:563:30: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: In unescapehex, line 561 lowercases with `c1 = (c1 - 'A') + 'a'` for every `c1 < 'a'`, and that includes digits. A digit like '0' (48) becomes 80. That is greater than '9', so the code takes the else branch on line 563 and computes `((80 - 'a') + 10) << 4 = (-7) << 4`. Digits are valid HEXCHARS, so the input is reachable and a negative value really is shifted. The shiftNegativeLHS warning was a true positive, and it also points at a real bug in the lowercasing. Removing it looks like a side effect of the PR dropping impossible bounds or conditional values in signed/unsigned arithmetic inference, so this is a lost true positive. ---- 33 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/n/nghttp2/nghttp2_1.70.0.orig.tar.gz Result: main nghttp2-1.70.0/third-party/mruby/mrbgems/mruby-bin-mirb/tools/mirb/mirb_buffer.c:880:29: style: Condition 'buf->cursor_lineline_count-1' is always false [knownConditionTrueFalse] nghttp2-1.70.0/third-party/mruby/mrbgems/mruby-bin-mirb/tools/mirb/mirb_buffer.c:870:46: note: Assuming that condition 'buf->line_count>1' is not redundant nghttp2-1.70.0/third-party/mruby/mrbgems/mruby-bin-mirb/tools/mirb/mirb_buffer.c:880:29: note: Condition 'buf->cursor_lineline_count-1' is always false Explanation: The `else if` at line 880 is reached when `line->len != 0` or when `buf->line_count <= 1`. On the first path, `line_count` can be greater than 1, so `cursor_line < line_count - 1` can be true (cursor at the end of a non-empty middle line). Main wrongly took `line_count <= 1` as given from the `&&` condition at line 870. It then pushed bounds through the unsigned subtraction `line_count - 1`. The PR stops impossible bounds from propagating through wrapping unsigned arithmetic, which removes this false positive. ---- 34 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/norm/norm_1.5.9+dfsg.orig.tar.xz Result: your src/common/normNode.cpp:3677:27: warning: Shifting 32-bit value by 100 bits is undefined behaviour. See condition at line 3666. [shiftTooManyBits] src/common/normNode.cpp:3666:20: note: Assuming that condition 'delta<-100' is not redundant src/common/normNode.cpp:3677:27: note: Shift Explanation: Line 3677 is reached only if `delta >= -100`, `delta >= -(int)lag_depth` and `delta < 0`. So the shift amount `-delta` is also limited by `lag_depth`. In NORM, `lag_depth` is a small history depth (set through `ChangeLagDepth`, which caps it), and `lag_mask` is a 32-bit mask. A shift by 100 would need `lag_depth >= 100`, which the class design does not allow. Cppcheck only takes the edge value -100 from the earlier `delta < -100` condition and ignores the tighter `-(int)lag_depth` guard. The new warning appeared because the PR's added cast bounds and inference changes. This looks like a new false positive. ---- 35 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/ntp/ntp_4.2.8p15+dfsg.orig.tar.xz Result: main ntp-4.2.8p15/libparse/ieee754io.c:356:38: error: Shifting by a negative value is undefined behaviour [shiftNegative] Explanation: Line 356 runs only inside `if (mbits > 31)`. In ntp's fetch_ieee754(), `mbits` is set to either 23 (single precision) or 52 (double precision), so in this branch the shift count `mbits - 33` is 19, never negative. Main reported the shift as negative because of a lower-bound value from the condition (mbits >= 32, so the shift count is >= -1). That value is only a minimum, not an actual possible value. The PR stops getValueLE() from treating lower-bound values as values that can be less than or equal to the limit, so this false positive goes away. ---- 36 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nut/nut_2.8.5.orig.tar.gz Result: main nut-2.8.5/drivers/bcmxcp.c:2532:32: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: The guard `if (sec < -1 || sec > 0x7FFF) return` deliberately lets `sec == -1` through; the comment says -1 means no automatic off/restart. So `sec>>8` can really shift a negative value. Cppcheck's shiftNegativeLHS check covers `>>` as well as `<<`. The warning was therefore a true positive by the checker's own rules, although for `>>` the behaviour is implementation-defined rather than undefined, so the finding is somewhat pedantic. The PR changes getValueLE to ignore values with a Lower bound. That drops the possible value -1 (meaning sec >= -1), even though it shows sec can equal -1, and the warning disappears. A real finding was lost because of a too-broad filter. ---- 37 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/q/qmlkonsole/qmlkonsole_26.04.0.orig.tar.xz Result: main qmlkonsole-26.04.0/lib/TerminalDisplay.cpp:1996:38: warning: Either the condition 'i>=0' is redundant, otherwise there is negative array index -1. [negativeContainerIndex] qmlkonsole-26.04.0/lib/TerminalDisplay.cpp:1995:19: note: Assuming that condition 'i>=0' is not redundant qmlkonsole-26.04.0/lib/TerminalDisplay.cpp:1996:38: note: Negative array index Explanation: The code checks `i >= 0 && i <= _imageSize` and then reads `_image[i - 1]`. If `i == 0` were reached, the index would be -1, so the guard does not match the access; a guard of `i > 0` would. This is exactly the inconsistency the "Either the condition is redundant..." check is built to report. The warning disappears because `getValueLE` now ignores values with a lower bound, so the value `i-1 >= -1` coming from `i >= 0` is no longer used. That change is not caused by Cppcheck understanding this code better, and it would suppress this kind of warning in general. In this particular code, `right.x() > 0` probably means `i` is never 0, so the warning may be harmless here. Low confidence. ---- 38 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/rplay/rplay_3.3.2.orig.tar.gz Result: main rplay-3.3.2/adpcm/g72x.c:347:16: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: In the final else branch, fa1 is known to lie in [-8191, 8191], so fa1 can be negative (for example -8191) when it is shifted. Main reported this through the possible value -8191 inferred from the 'fa1 < -8191' check. The PR changes getValueLE to ignore values with Bound::Lower. But a lower-bound value of -8191 means 'fa1 >= -8191', and -8191 itself is still reachable. Removing this negative-LHS shift warning therefore loses a true positive under Cppcheck's own check semantics. ---- 39 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/smartlist/smartlist_3.15.orig.tar.gz Result: main procmail-3.15/src/misc.c:324:43: style: Condition 'c-'A'<='Z'-'A'' is always false [knownConditionTrueFalse] procmail-3.15/src/misc.c:324:27: note: Assuming that condition 'c-'a'<='z'-'a'' is not redundant procmail-3.15/src/misc.c:324:43: note: Condition 'c-'A'<='Z'-'A'' is always false Explanation: `c` is `unsigned`, so `c-'a'` and `c-'A'` are unsigned subtractions that wrap around. That is the usual unsigned-range trick for testing for a lowercase or uppercase letter. If `c-'a'<='z'-'a'` is false, then `c` is not in 'a'..'z', but `c` can still be in 'A'..'Z'. In that case `c-'A'` wraps to 0..25 and the second condition is true. So the 'always false' warning was a false positive caused by carrying bounds through wrapping unsigned arithmetic. The PR stops that propagation, so removing this warning is correct. ---- 40 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/tetrinet/tetrinet_0.11+git20080905.a98fcc1.orig.tar.xz Result: main tetrinet-0.11+git20080905.a98fcc1/server.c:414:23: warning: Either the condition 'winner<0' is redundant or the array 'teams[6]' is accessed at index -1, which is out of bounds. [negativeIndex] tetrinet-0.11+git20080905.a98fcc1/server.c:412:17: note: Assuming that condition 'winner<0' is not redundant tetrinet-0.11+git20080905.a98fcc1/server.c:414:23: note: Negative array index Explanation: `winner` starts at -1 and is set to `i` (1..6) the first time the `if (winner < 0)` branch runs. The `else` branch at line 414 only runs when `winner >= 0`, which in practice means `winner >= 1`. So `teams[winner-1]` can never use index -1. The old warning came from wrongly treating `winner == 0` as a possible value. Removing this false positive is an improvement. ---- 41 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/tinyexr/tinyexr_1.0.13+dfsg.orig.tar.xz Result: main tinyexr-1.0.13/tinyexr_huffman.hh:1501:26: style: Condition 'src_len-offset<4' is always false [knownConditionTrueFalse] tinyexr-1.0.13/tinyexr_huffman.hh:1479:17: note: Assuming that condition 'src_len<6' is not redundant tinyexr-1.0.13/tinyexr_huffman.hh:1487:22: note: Assuming condition is false tinyexr-1.0.13/tinyexr_huffman.hh:1490:33: note: Assuming condition is false tinyexr-1.0.13/tinyexr_huffman.hh:1496:13: note: Assuming condition is false tinyexr-1.0.13/tinyexr_huffman.hh:1501:26: note: Condition 'src_len-offset<4' is always false Explanation: The early return at line 1479 guarantees `src_len >= 6`, and `offset` is the constant 2. So `src_len - offset >= 4`, no wrap-around is possible, and `src_len - offset < 4` really is always false. The removed knownConditionTrueFalse warning was a true positive. The PR now drops all impossible bounds on unsigned `+`/`-`/`*` results, even when the operand ranges prove the operation cannot wrap. That over-broad rule lost this valid finding. ---- 42 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vpb-driver/vpb-driver_4.2.61.orig.tar.gz Result: main vpb-driver-4.2.61/src/libvpb/modulate.h:27:12: warning: Array 'in[0]' accessed at index -6, which is out of bounds. [negativeIndex] vpb-driver-4.2.61/src/libvpb/cid.cpp:163:44: note: Calling function 'filter', 3rd argument '7' value is 7 vpb-driver-4.2.61/src/libvpb/modulate.h:26:17: note: Assuming that condition 'i0' is always true [knownConditionTrueFalse] xrootd-6.2.0/src/XrdCl/XrdClFS.cc:805:12: note: Assuming that condition 'argc<2' is not redundant xrootd-6.2.0/src/XrdCl/XrdClFS.cc:821:16: note: Condition 'argc-1>0' is always true Explanation: `argc` is `uint32_t`, and the earlier `if (argc < 2) return` guarantees `argc >= 2`. So `argc - 1` is always at least 1 and cannot wrap, which makes `argc - 1 > 0` always true. The old warning was a true positive. The PR now drops every impossible non-point bound on unsigned `+`/`-`/`*`, even when wrap-around is impossible, so this valid redundant-condition warning is lost. ---- 45 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/x/xrootd/xrootd_6.2.0.orig.tar.gz Result: main xrootd-6.2.0/src/XrdOss/XrdOssRename.cc:171:14: warning: Either the condition '(lnklen=readlink(old_path,oldlnk,sizeof(oldlnk)-1))<0' is redundant or the array 'oldlnk[0]' is accessed at index -1, which is out of bounds. [negativeIndex] xrootd-6.2.0/src/XrdOss/XrdOssRename.cc:165:62: note: Assuming that condition '(lnklen=readlink(old_path,oldlnk,sizeof(oldlnk)-1))<0' is not redundant xrootd-6.2.0/src/XrdOss/XrdOssRename.cc:171:14: note: Negative array index Explanation: After `if ((lnklen = readlink(...)) < 0) return`, lnklen can be 0 as far as the code shows. In that case `oldlnk[lnklen-1]` reads `oldlnk[-1]`. Main reports this as the usual 'condition redundant or negative index' warning, and that warning is valid for the code as written: nothing guards against a zero-length result. Linux never returns 0 for a symlink, but some other systems allow empty symlinks, so this is a real latent bug rather than a clear false positive. The warning disappears because the PR changed `getValueLE` to ignore values with `Bound::Lower`. A lower-bound possible value of -1 means the index can be -1 (or more), so ignoring it hides a real out-of-bounds path rather than reflecting better understanding. The same run also lost the correct 'argc-1>0 always true' warning, which suggests the PR is over-suppressing in general. ---- 46 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xye/xye_0.12.2+dfsg.orig.tar.gz Result: main xye-0.12.2+dfsg/src/font.cpp:254:43: warning: Either the condition 'charoffset<0' is redundant or the array 'CharPos[512]' is accessed at index -1, which is out of bounds. [negativeIndex] xye-0.12.2+dfsg/src/font.cpp:247:37: note: Assuming that condition 'charoffset<0' is not redundant xye-0.12.2+dfsg/src/font.cpp:254:43: note: Negative array index Explanation: `charoffset = ((int)(*c - 33)) * 2 + 1` is always odd. After the `charoffset < 0` guard continues the loop, `charoffset` is at least 1, so `CharPos[charoffset-1]` never reaches index -1. The warning was a false positive: Cppcheck took the lower bound `charoffset >= 0` from the condition and assumed `charoffset == 0`. The PR stops `getValueLE` from using such lower-bound values (the new `array_index_77` test covers a similar pattern), so removing this false positive is an improvement. ---- 47 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/x/xye/xye_0.12.2+dfsg.orig.tar.gz Result: main xye-0.12.2+dfsg/src/font.cpp:257:49: warning: Either the condition 'charoffset<0' is redundant or the array 'CharPos[512]' is accessed at index -1, which is out of bounds. [negativeIndex] xye-0.12.2+dfsg/src/font.cpp:247:37: note: Assuming that condition 'charoffset<0' is not redundant xye-0.12.2+dfsg/src/font.cpp:257:49: note: Negative array index Explanation: `charoffset = (int)(*c - 33) * 2 + 1` is always odd. Any value that gets past the `charoffset < 0` check (which does `continue`) is therefore at least 1, so `CharPos[charoffset-1]` is indexed at 0 or more. Index -1 would need `charoffset == 0`, which can never happen. The removed negativeIndex warning was a false positive, so removing it is an improvement. ---- 48 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xye/xye_0.12.2+dfsg.orig.tar.gz Result: main xye-0.12.2+dfsg/src/font.cpp:258:59: warning: Either the condition 'charoffset<0' is redundant or the array 'CharPos[512]' is accessed at index -1, which is out of bounds. [negativeIndex] xye-0.12.2+dfsg/src/font.cpp:247:37: note: Assuming that condition 'charoffset<0' is not redundant xye-0.12.2+dfsg/src/font.cpp:258:59: note: Negative array index Explanation: The removed warning is a false positive. `charoffset = (*c - 33) * 2 + 1` is always odd, so it can never be 0. The guard `charoffset < 0 || charoffset > MaxPos` then `continue` ensures charoffset >= 1 at line 258, so `CharPos[charoffset-1]` is never accessed at index -1. Main took the boundary value 0 implied by the `charoffset < 0` guard as a possible value, which gives index -1. The PR's `getValueLE` change stops lower-bound values from being treated as reachable small values, which removes this spurious negativeIndex report. ---- 49 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xye/xye_0.12.2+dfsg.orig.tar.gz Result: main xye-0.12.2+dfsg/src/font.cpp:410:53: warning: Either the condition 'charoffset<0' is redundant or the array 'CharPos[512]' is accessed at index -1, which is out of bounds. [negativeIndex] xye-0.12.2+dfsg/src/font.cpp:400:41: note: Assuming that condition 'charoffset<0' is not redundant xye-0.12.2+dfsg/src/font.cpp:410:53: note: Negative array index Explanation: Line 389 computes `charoffset = ((int)(*c - 33)) * 2 + 1`, so `charoffset` is always odd and can never be 0. After the guard `charoffset < 0` on line 400, `charoffset` is at least 1, so `CharPos[charoffset-1]` is never accessed at index -1. Main reasoned only from the guard (`charoffset >= 0`, so `charoffset-1 >= -1`) and reported a false positive. The PR's changes to bound handling (`getValueLE` ignoring lower-bound values, and no impossible-bound propagation through unsigned arithmetic) remove this false warning. ---- 50 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xye/xye_0.12.2+dfsg.orig.tar.gz Result: main xye-0.12.2+dfsg/src/font.cpp:411:63: warning: Either the condition 'charoffset<0' is redundant or the array 'CharPos[512]' is accessed at index -1, which is out of bounds. [negativeIndex] xye-0.12.2+dfsg/src/font.cpp:400:41: note: Assuming that condition 'charoffset<0' is not redundant xye-0.12.2+dfsg/src/font.cpp:411:63: note: Negative array index Explanation: The removed warning is a false positive. `charoffset` is computed as `((int)(*c - 33)) * 2 + 1`, so it is always odd. After the guard `charoffset < 0 || charoffset > MaxPos` skips negative values, the smallest possible value is 1. That makes `charoffset-1` at least 0, so `CharPos[charoffset-1]` is never accessed at index -1. Cppcheck only saw the lower bound `charoffset >= 0` from the guard and ignored the odd parity. The PR's change to `getValueLE`, which ignores lower-bound values, removes the warning. That change looks broad and may hide some true positives elsewhere, but for this code dropping the warning is correct.