AI review of 2026-10-18_05-09-04-7ad365afc2da-results.txt PR: #8819 https://github.com/cppcheck-opensource/cppcheck/pull/8819 Tested: 7ad365afc2da4dd1a39b8b3c8b48e17b56b2731c Merge base: b2d83612a1d235901d70a77d25c21759014e4919 Reviewed: 2026-10-19 01:58:19 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 3131 in the report (random sample), 50 not reviewed: valueFlowMaxIterations Verdicts: 42 improvement, 6 neutral, 2 regression Tokens: 133420 input, 3247840 cache read, 811960 cache write, 21407 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/a/apertium/apertium_3.9.12.orig.tar.bz2 Result: main apertium-3.9.12/apertium/win32/libgen.c:13:16: style: Condition 'pos+1!=NULL' is always true [knownConditionTrueFalse] Explanation: The code is `if (pos != NULL) { if (pos + 1 != NULL) ...`. Inside the branch where pos is non-null, pos+1 cannot be NULL, so the warning is a true positive in both versions. The only change is that the PR adds an error-path note pointing to the guarding condition 'pos!=NULL' on line 12. That makes the message more informative and accurate about why the condition is always true. ---- 2 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/bash/bash_5.3.orig.tar.xz Result: your bash-5.3/builtins/bashgetopt.c:69:29: style: Condition 'lhead==0' is always false [knownConditionTrueFalse] bash-5.3/builtins/bashgetopt.c:62:11: note: Assuming that condition 'list==0' is not redundant bash-5.3/builtins/bashgetopt.c:69:11: note: Assuming that condition 'list!=lhead' is not redundant bash-5.3/builtins/bashgetopt.c:69:29: note: Condition 'lhead==0' is always false Explanation: The warning is a true positive. Line 62 returns when `list == 0`, so `list` is non-null at line 69. The `lhead == 0` operand is only evaluated when `list == lhead`, so `lhead` is non-null there and the condition is always false. The warning text is unchanged; the PR only adds an error path. That path points to the `list==0` check and the `list!=lhead` short-circuit, which is exactly the reasoning behind the warning. This makes the message easier to understand. ---- 3 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/bogl/bogl_0.1.18.orig.tar.gz Result: your bogl-0.1.18/bogl-term.c:244:21: style: Condition 'term->screen[i]' is always true [knownConditionTrueFalse] bogl-0.1.18/bogl-term.c:241:12: note: Assuming that condition '!term->screen[i]' is not redundant bogl-0.1.18/bogl-term.c:244:21: note: Condition 'term->screen[i]' is always true Explanation: The `while (!term->screen[i])` loop only exits once `term->screen[i]` is non-zero, so the condition `if (term->screen[i])` on line 244 really is always true. Main and the PR both report this true positive. The PR adds an error-path note pointing to the loop condition at line 241, which tells the user why the condition is known. That makes the message more informative. ---- 4 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/cellwriter/cellwriter_1.3.6.orig.tar.gz Result: your cellwriter-1.3.6/src/cellwidget.c:761:18: style: Condition 'input' is always true [knownConditionTrueFalse] cellwriter-1.3.6/src/cellwidget.c:752:13: note: Assuming that condition '!input' is not redundant cellwriter-1.3.6/src/cellwidget.c:757:13: note: Assuming condition is false cellwriter-1.3.6/src/cellwidget.c:761:18: note: Condition 'input' is always true Explanation: Line 752 returns early when `!input`, and nothing between there and line 761 modifies the global `input`. So `input` is non-null in the else-if, and the warning is a true positive in both versions. The only difference is that the PR adds an error path. It points to the `!input` check at line 752 that makes the condition redundant, and to the `training` branch at 757. This explains why the condition is always true, so the message is more useful to the user. ---- 5 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/chuck/chuck_1.5.5.8.orig.tar.xz Result: your chuck-1.5.5.8/src/core/lo/server.c:2295:13: style: Condition 'it' is always true [knownConditionTrueFalse] chuck-1.5.5.8/src/core/lo/server.c:2278:12: note: Assuming that condition 'it' is not redundant chuck-1.5.5.8/src/core/lo/server.c:2282:16: note: Assuming condition is false chuck-1.5.5.8/src/core/lo/server.c:2295:13: note: Condition 'it' is always true Explanation: Both versions report the same warning at line 2295. Only the error path changed: the PR adds notes pointing to `while (it)` at line 2278 and to the `it == m` branch at line 2282. The warning is a true positive. Inside `while (it)`, `it` is non-null, and the only path to line 2295 is when `it != m` (the other branch returns), so `if (it)` is always true. The new notes point to the loop condition, which is the real reason the check is redundant. That makes the diagnostic easier to understand and no less accurate. ---- 6 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/conky/conky_1.24.2+dfsg.orig.tar.xz Result: main conky-1.24.2/3rdparty/Vc/src/cpuid.cpp:249:29: style: Condition 'eax&0x1f' is always true [knownConditionTrueFalse] conky-1.24.2/3rdparty/Vc/src/cpuid.cpp:248:15: note: Assignment 'eax=1', assigned value is 1 conky-1.24.2/3rdparty/Vc/src/cpuid.cpp:249:29: note: Condition 'eax&0x1f' is always true Explanation: `eax` is set to 1 before the loop, but each iteration runs `Vc_CPUID_C(4, i)`, which overwrites `eax` (via inline asm or a cpuid intrinsic). The loop condition `eax & 0x1f` is therefore what ends the loop once CPUID reports no more cache levels. Saying it is always true is a false positive, probably caused by Cppcheck not seeing the asm outputs. Removing the warning is good for users. ---- 7 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/f/fastdds/fastdds_3.6.1+ds.orig.tar.xz Result: your fastdds-3.6.1/src/cpp/rtps/transport/shared_mem/SharedMemManager.hpp:755:25: style: Condition 'buffer_ref' is always true [knownConditionTrueFalse] fastdds-3.6.1/src/cpp/rtps/transport/shared_mem/SharedMemManager.hpp:751:67: note: Assignment 'buffer_ref=std::make_shared(segment,buffer_descriptor.source_segment_id,buffer_node,buffer_descriptor.validity_id)', assigned value is never 0 fastdds-3.6.1/src/cpp/rtps/transport/shared_mem/SharedMemManager.hpp:755:25: note: Condition 'buffer_ref' is always true Explanation: The same warning appears in both main and your. The text of the main line and the your line is identical, so the diff probably only reflects a change in the attached notes or error path. Both versions report that `buffer_ref` assigned from `std::make_shared` is never null, so `if (buffer_ref)` is always true. That is a true positive: `make_shared` throws on failure and never returns null. Users see the same result either way. ---- 8 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/f/feenox/feenox_1.2.orig.tar.gz Result: main feenox-1.2/src/parser/parser.c:2760:73: style: Condition 'strcasecmp(token,"DIM")==0' is always false [knownConditionTrueFalse] Explanation: The warning itself is a true positive. In the else-if chain, line 2754 already handles `strcasecmp(token,"DIM")==0`, so the same check at line 2760 can never be true. The PR does not drop the warning; it only changes the message, which now adds a note pointing to the earlier condition at 2754:80. That error path explains why the condition is always false, so the message is more accurate and more helpful. ---- 9 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/fvwm1/fvwm1_1.24r.orig.tar.gz Result: main fvwm1-1.24r.orig/modules/FvwmIconBox/FvwmIconBox.c:1305:11: style: Condition 'new!=NULL' is always true [knownConditionTrueFalse] Explanation: The warning itself is unchanged and correct: after `if (new == NULL) return;`, `new != NULL` at line 1305 is always true. The only difference is that the PR now adds an error path note pointing to the `new==NULL` check at line 1300. The "main" line disappears only because the message changed and now carries that note. The note explains why the condition is always true, so the message is more accurate and more helpful. ---- 10 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/gensio/gensio_3.0.4.orig.tar.gz Result: main gensio-3.0.4/lib/gensio_ax25.c:1953:16: style: Condition 'chan->conf.addr' is always true [knownConditionTrueFalse] Explanation: The warning is still reported. The only change is that the PR adds an error-path note pointing at the guarding condition 'chan && chan->conf.addr' on line 1950. Inside that block, 'chan->conf.addr' is known non-null, so the inner check on line 1953 is truly redundant and the warning is a true positive. The new note shows the user why the condition is always true, which makes the message more informative. ---- 11 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gensio/gensio_3.0.4.orig.tar.gz Result: main gensio-3.0.4/lib/gensio_ratelimit.c:463:9: style: Condition 'parms' is always true [knownConditionTrueFalse] Explanation: The warning is a true positive both before and after the PR. At line 458 the function returns early when `parms` is NULL, so `if (parms)` at line 463 is always true. The text of the warning is unchanged. The new version adds an error path that points back to the `!parms` check at line 458, which explains why the condition is always true. The main line only disappears because the warning text changed, so the message is more informative and nothing is lost. ---- 12 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/gmpc/gmpc_11.8.16.orig.tar.gz Result: main gmpc-11.8.16/src/Tools/misc.c:418:9: style: Condition 'a->directory' is always true [knownConditionTrueFalse] Explanation: On line 418, 'a->directory' is truly always true. The enclosing branch at line 415 only runs when 'a->directory && b->directory' holds, so the inner check is redundant. The warning is kept by the PR. Only its form changed: it now carries an error path ('Assuming that condition ... is not redundant' at 415:13). That points the user to the condition that makes it always true, so the message is more accurate. ---- 13 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/goban/goban_1.1.orig.tar.gz Result: main goban-1.1.orig/src/but.c:965:9: style: Condition 'status' is always true [knownConditionTrueFalse] Explanation: The same warning appears in both runs. The 'main' line has no notes and the 'your' line adds the note "Assuming that condition '!status' is not redundant" at line 962. The warning itself is correct: line 962 breaks out of the loop when '!status' holds, so 'status' is always true at line 965. Only the error path now carries the condition location. That makes the message slightly more informative, but the finding is unchanged, so this is effectively neutral. ---- 14 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/goban/goban_1.1.orig.tar.gz Result: your goban-1.1.orig/src/play.c:882:28: style: Comparing expression of type 'bool' against value -1. Condition is always true. [compareValueOutOfTypeRangeError] Explanation: `alreadyDead` is declared `bool` and is assigned the result of a comparison (`waitpid(...) != 0`), so it can only be 0 or 1. `assert(alreadyDead != -1)` is therefore always true. The original intent was probably to check `waitpid()` for -1, and the assert as written does nothing. The new compareValueOutOfTypeRangeError is a correct, useful finding. It appears now likely because the PR removed the early return for an unspecified platform. ---- 15 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/iqtree3/iqtree3_3.1.4+dfsg.orig.tar.xz Result: main iqtree3-3.1.4/terrace/presenceabsencematrix.cpp:864:43: style: Condition 'val==max_overlap' is always false [knownConditionTrueFalse] Explanation: Line 864 is `if(val==max_overlap or val==max_overlap)`. The second operand is a copy of the first, so it is only evaluated when the first was false and is then always false. The warning is a true positive. The PR does not remove it: the same warning is still reported at 864:43, now with an error path pointing to the first `val==max_overlap` at 864:23 as the assumed condition. That explains why the condition is always false, so the message is more informative. This matches the PR's updated tests, which now expect such `->` error paths for knownConditionTrueFalse. ---- 16 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/irssi/irssi_1.4.5.orig.tar.xz Result: main irssi-1.4.5/src/fe-common/irc/fe-irc-queries.c:86:15: style: Condition 'address!=NULL' is always true [knownConditionTrueFalse] Explanation: Both versions report the same true positive. Line 66 returns early when `address == NULL`, so `address != NULL` at line 86 is always true. The only difference is that the PR's output now carries an error path pointing back to the guard at line 66, which explains why the condition is always true. The extra note at 84:36 ('Assuming condition is false') is slightly noisy, but overall the message is more informative, matching the PR's test updates that add condition locations to knownConditionTrueFalse paths. ---- 17 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/k/ksh/ksh_2020.0.0+really93u+20120801.orig.tar.gz Result: main ksh-93u+20120801/src/cmd/ksh93/edit/vi.c:325:17: style: Condition 'term_char=='\n'' is always false [knownConditionTrueFalse] Explanation: Same warning in both versions; the PR only adds notes. When VEOL2 and ECHOCTL are undefined, the block at line 319 returns if term_char=='\n', so at line 325 term_char=='\n' really is always false in that configuration. The warning is a true positive (configuration-dependent). The new notes point to the earlier check at line 319 that makes it false, which makes the message easier to understand. ---- 18 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/k/kst/kst_2.0.8.orig.tar.gz Result: main Kst-2.0.8/src/libkstapp/view.cpp:283:13: style: Condition 'viewItem' is always true [knownConditionTrueFalse] Explanation: At line 283, `viewItem` cannot be null because line 277 runs `continue` when it is. So 'Condition viewItem is always true' is a true positive. The PR does not drop the warning: the same message appears on a 'your' line with notes added. The main/your pair only shows that the error path changed, and it now points to line 277 ('Assuming that condition !viewItem is not redundant'). The warning is the same but easier for users to understand. ---- 19 / 50 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/l/latte-dock/latte-dock_0.10.9.orig.tar.xz Result: your latte-dock-0.10.9/app/view/contextmenu.cpp:363:21: style: Condition 'applet' is always true [knownConditionTrueFalse] latte-dock-0.10.9/app/view/contextmenu.cpp:305:13: note: Assuming that condition 'applet' is not redundant latte-dock-0.10.9/app/view/contextmenu.cpp:310:17: note: Assuming condition is true latte-dock-0.10.9/app/view/contextmenu.cpp:319:39: note: Assuming condition is false latte-dock-0.10.9/app/view/contextmenu.cpp:363:21: note: Condition 'applet' is always true Explanation: Main already reported 'applet' as always true at line 363. The PR only adds error-path notes pointing at line 305 (where 'applet' is checked) and the branch assumptions at lines 310 and 319. The PR's test updates show the same pattern: knownConditionTrueFalse messages gain the originating condition location. The warning itself is unchanged, and the extra trace helps users see why Cppcheck considers 'applet' non-null. Lines 305–319 are not shown, so I cannot confirm the path is accurate, hence low confidence. ---- 20 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/l/lbdb/lbdb_0.57.orig.tar.gz Result: main lbdb-0.57/fetchaddr.c:91:11: style: Condition 'p->personal' is always true [knownConditionTrueFalse] Explanation: Line 87 checks `p->personal`, so the second check on line 91 is always true. The warning is a true positive in both versions. The PR only changed the message: it now has an error path note that points to the condition at line 87:51. That is more informative, so it is a small improvement in message accuracy. ---- 21 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/l/lepton-eda/lepton-eda_1.9.18.orig.tar.gz Result: your lepton-eda-1.9.18/liblepton/src/component_object.c:1525:11: style: Condition 'inside' is always true [knownConditionTrueFalse] lepton-eda-1.9.18/liblepton/src/component_object.c:1520:7: note: Assuming that condition 'inside' is not redundant lepton-eda-1.9.18/liblepton/src/component_object.c:1523:27: note: Assuming condition is true lepton-eda-1.9.18/liblepton/src/component_object.c:1525:11: note: Condition 'inside' is always true Explanation: The warning itself is unchanged. 'inside' is checked at line 1520 and not modified before line 1525, so the inner 'if (inside)' is indeed always true, and both versions correctly report it. The PR only adds an error path showing the dominating condition at 1520 and the enclosing condition at 1523. That makes the message more informative and accurate for users, consistent with the updated tests that now expect '->' location chains. ---- 22 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libm/libmatchbox/libmatchbox_1.12+git20170224.orig.tar.xz Result: your libmatchbox/libmb/mbmenu.c:1171:16: style: Condition 'menu->items' is always true [knownConditionTrueFalse] libmatchbox/libmb/mbmenu.c:1161:20: note: Assuming that condition 'menu->items==NULL' is not redundant libmatchbox/libmb/mbmenu.c:1167:30: note: Assuming condition is true libmatchbox/libmb/mbmenu.c:1169:14: note: Assuming condition is true libmatchbox/libmb/mbmenu.c:1171:16: note: Condition 'menu->items' is always true Explanation: Line 1171 sits in the else branch of `if (menu->items == NULL)`, and `menu->items` is not changed before it, so 'menu->items' really is always true. Both versions report this true positive. The PR only adds an error path: notes pointing to the `menu->items==NULL` check at line 1161 and the branch conditions leading to line 1171. That matches the PR's test updates, which add the originating condition location to knownConditionTrueFalse messages. The message is now more informative and correctly explains why the condition is always true. ---- 23 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libm/libmawk/libmawk_1.0.5.orig.tar.bz2 Result: main libmawk-1.0.5/src/libmawk/rexp/rexpdb.c:52:27: warning: Either the condition 'p->type>=(2*10)' is redundant or the array 'xlat[10]' is accessed at index 19, which is out of bounds. [arrayIndexOutOfBoundsCond] libmawk-1.0.5/src/libmawk/rexp/rexpdb.c:47:30: note: Assuming that condition 'p->type>=(2*10)' is not redundant libmawk-1.0.5/src/libmawk/rexp/rexpdb.c:52:27: note: Array index out of bounds Explanation: The guard at line 47 only rejects values below 0 or at least END_ON (20). After it, `p->type` can be anywhere in 0..19, but `xlat` has only 10 entries. So `xlat[(int)p->type]` can be read out of bounds for values 10..19. These values match mawk's U_ON offset (10), and upstream mawk later changed this line to index with `% U_ON`, which suggests the bug is real. The removed warning therefore points at a genuine mismatch between the guard and the array size. The PR likely dropped it because of its new cast and value-range handling of `(int)p->type`, so a true positive was lost. ---- 24 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libn/libnginx-mod-http-zstd/libnginx-mod-http-zstd_0.90.9.orig.tar.gz Result: main myguard-labs-nginx-zstd-module-3486b5b/ci/tests/unit/test_vary_fusion.c:107:18: style: Condition 'last==NULL' is always false [knownConditionTrueFalse] Explanation: The warning at line 107 is still reported; only its supporting notes changed. `arena_alloc()` either calls `abort()` or returns `&arena[arena_used]`, which can never be NULL, so `last==NULL` is truly always false. The new version gives the same true positive with an accurate error path: the non-null assignment at line 82, then the call at line 106. That makes the message more informative, assuming the main line had no such notes, which the diff layout suggests but does not prove. ---- 25 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libn/libnginx-mod-http-zstd/libnginx-mod-http-zstd_0.90.9.orig.tar.gz Result: your myguard-labs-nginx-zstd-module-3486b5b/ci/tests/unit/test_vary_fusion.c:107:18: style: Condition 'last==NULL' is always false [knownConditionTrueFalse] myguard-labs-nginx-zstd-module-3486b5b/ci/tests/unit/test_vary_fusion.c:82:9: note: Assignment 'p=&arena[arena_used]', assigned value is never 0 myguard-labs-nginx-zstd-module-3486b5b/ci/tests/unit/test_vary_fusion.c:106:27: note: Calling function 'arena_alloc' returns !0 myguard-labs-nginx-zstd-module-3486b5b/ci/tests/unit/test_vary_fusion.c:107:18: note: Condition 'last==NULL' is always false Explanation: The same warning, with the same message and notes, appears in both main and your. Only the order of the main/your lines shifted in the diff, or some invisible detail changed, so nothing changes for users. arena_alloc returns &arena[...], which is never NULL (it aborts on exhaustion), so the warning is a true positive either way. ---- 26 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libt/libtext-markdown-discount-perl/libtext-markdown-discount-perl_0.18.orig.tar.gz Result: your Text-Markdown-Discount-0.18/discount-2.2.7d/generate.c:876:16: style: Condition 'count' is always true [knownConditionTrueFalse] Text-Markdown-Discount-0.18/discount-2.2.7d/generate.c:873:34: note: Assuming that condition 'count=nrticks(size+ticks,tickchar,f)' is not redundant Text-Markdown-Discount-0.18/discount-2.2.7d/generate.c:874:17: note: Assuming condition is false Text-Markdown-Discount-0.18/discount-2.2.7d/generate.c:876:16: note: Condition 'count' is always true Explanation: In `matchticks()`, the inner block is only entered when `(c == tickchar) && (count = nrticks(...))` is true, so `count` is nonzero there. The `else if ( count )` on line 876 is therefore always true, and the warning is a true positive. Main and this PR both report it with the same message. The difference is the error path: the PR adds notes pointing at the assignment-condition on line 873 that makes `count` nonzero. That explains why the condition is always true and does not change the verdict of the warning, so it is a slightly more informative diagnostic. ---- 27 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libt/libtext-markdown-discount-perl/libtext-markdown-discount-perl_0.18.orig.tar.gz Result: your Text-Markdown-Discount-0.18/discount-2.2.7d/tools/pandoc_headers.c:65:7: style: Condition 'opt' is always true [knownConditionTrueFalse] Text-Markdown-Discount-0.18/discount-2.2.7d/tools/pandoc_headers.c:64:17: note: Assuming that condition 'opt=gethopt(&blob,opts,sizeof(opts)/sizeof(opts[0]))' is not redundant Text-Markdown-Discount-0.18/discount-2.2.7d/tools/pandoc_headers.c:65:7: note: Condition 'opt' is always true Explanation: Inside `while (opt = gethopt(...))` the pointer `opt` is non-null, so the check `if (opt && ...)` at line 65 really is always true. Main already reported this, so the warning is a true positive. The only difference is that the new message has an error path: it points to the loop condition at line 64 as the reason. That makes the warning easier to understand, so the message is more accurate. ---- 28 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/mcl14/mcl14_14-137+ocaml.orig.tar.xz Result: main mcl-14-137/src/shcl/clmdag.c:76:19: style: Condition '!strcmp(argv[a],"-h")' is always false [knownConditionTrueFalse] Explanation: The warning is still reported. The only change is that the PR adds an error path pointing to the earlier identical check at line 62 '!strcmp(argv[a],"-h")'. The second '-h' test at line 76 is in the same else-if chain, so it can only be reached when the first one was false, and argv[a] is not modified in between. The warning is a true positive, and the new message with its notes is more informative. ---- 29 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mcl14/mcl14_14-137+ocaml.orig.tar.xz Result: main mcl-14-137/src/shmx/mcxcollect.c:266:42: style: Condition 'get_header' is always true [knownConditionTrueFalse] Explanation: The PR does not remove this warning. The same knownConditionTrueFalse warning at 266:42 is re-reported by the PR build, only with added error-path notes ('Assuming that condition get_header is not redundant' at 265:40). The warning is a false positive in both versions. `get_header` is `collect_g != 'p' && !ct`, so the ternary's true branch (`collect_g == 'p' || get_header`) is also taken when `collect_g == 'p'`. In that case `get_header` is false, so `get_header ? 1 : 0` at line 266 is not always true. The only difference is extra path notes on an unchanged false positive, which does not matter to users either way. ---- 30 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/n/neovim/neovim_0.12.4.orig.tar.xz Result: main neovim-0.12.4/src/mpack/conv.c:123:27: style: Condition 'tok.data.value.lo==0' is always false [knownConditionTrueFalse] neovim-0.12.4/src/mpack/conv.c:121:44: note: Assignment 'tok.data.value.lo=~tok.data.value.lo+1', assigned value is greater than 0 neovim-0.12.4/src/mpack/conv.c:123:27: note: Condition 'tok.data.value.lo==0' is always false Explanation: `tok.data.value.lo` is an unsigned 32-bit value. The expression `~lo + 1` wraps to 0 when `lo` is 0, which happens when `vabs` is a multiple of 2^32. So the claim "assigned value is greater than 0" is wrong, and `lo == 0` can be true. Main reported a false positive because it ignored unsigned wraparound. The PR adds wrap-aware unsigned arithmetic handling, so removing this warning is correct. ---- 31 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/n/nettle4/nettle4_4.0.orig.tar.gz Result: main nettle-4.0/serpent-decrypt.c:500:4: warning: Either the condition 'k>0' is redundant or the array 'ctx->keys[33][4]' is accessed at index 4294967296, which is out of bounds. [arrayIndexOutOfBoundsCond] nettle-4.0/serpent-decrypt.c:497:16: note: Assuming that condition 'k>0' is not redundant nettle-4.0/serpent-decrypt.c:499:4: note: Compound assignment '-=', assigned value is -7 nettle-4.0/serpent-decrypt.c:500:4: note: Array index out of bounds Explanation: `k` starts at 24 and only ever decreases by 8 inside `while (k > 0)`, so it takes the values 24, 16, 8 and 0 and never wraps. The old warning came from treating `k > 0` as `k >= 1`, computing `k -= 8` as -7, and then reporting a wrapped index of 4294967296. That path cannot happen, so the warning was a false positive. The PR stops carrying range bounds through unsigned arithmetic that may wrap, which removes this bogus out-of-bounds index. ---- 32 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/n/nettle4/nettle4_4.0.orig.tar.gz Result: main nettle-4.0/serpent-decrypt.c:504:4: warning: Either the condition 'k>0' is redundant or the array 'ctx->keys[33][4]' is accessed at index 4294967293, which is out of bounds. [arrayIndexOutOfBoundsCond] nettle-4.0/serpent-decrypt.c:497:16: note: Assuming that condition 'k>0' is not redundant nettle-4.0/serpent-decrypt.c:499:4: note: Compound assignment '-=', assigned value is -7 nettle-4.0/serpent-decrypt.c:504:4: note: Array index out of bounds Explanation: `k` is an unsigned loop counter. It starts at 24, the loop is entered via goto, and the loop runs only while k>0, with `k -= 8` at the top of the body. So k takes the values 24, 16, 8, 0, and the largest index used is k+7=31 < 33. The warning came from main assuming k could be 1 when k>0 holds. Then k-8 = -7 wraps to 4294967289, and k+4 gives index 4294967293. That path is infeasible because k is always a multiple of 8. The PR's handling of unsigned wraparound and range bounds drops this bogus wrapped value, so removing the false positive is an improvement. ---- 33 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/openbox/openbox_3.7~rc2.orig.tar.xz Result: main openbox-release-3.7-rc2/obt/tests/bstest.c:38:5: warning: Either the condition 'out_BSEARCH>0' is redundant or the array 'ar[18]' is accessed at index 2147483648, which is out of bounds. [arrayIndexOutOfBoundsCond] openbox-release-3.7-rc2/obt/tests/bstest.c:38:5: note: Assuming that condition 'out_BSEARCH>0' is not redundant openbox-release-3.7-rc2/obt/tests/bstest.c:38:5: note: Assignment 'l_BSEARCH=out_BSEARCH+1', assigned value is 1 openbox-release-3.7-rc2/obt/tests/bstest.c:38:5: note: Assuming condition is false openbox-release-3.7-rc2/obt/tests/bstest.c:38:5: note: Assuming condition is true openbox-release-3.7-rc2/obt/tests/bstest.c:38:5: note: Assuming condition is false openbox-release-3.7-rc2/obt/tests/bstest.c:38:5: note: Assignment 'out_BSEARCH=l_BSEARCH+(r_BSEARCH-l_BSEARCH)/2', assigned value is 2147483648 openbox-release-3.7-rc2/obt/tests/bstest.c:38:5: note: Array index out of bounds Explanation: Openbox's BSEARCH macro uses unsigned `guint` indices. When the value is smaller than `ar[0]`, it sets `r_BSEARCH = (guint)-1`, and the loop condition `r_BSEARCH != (guint)-1` then ends the loop. The removed warning assumes the loop keeps running with `l=1` and `r=UINT_MAX`, which gives the out-of-bounds index 2147483648. That state never reaches the array access, so the warning was a false positive. The PR's stricter handling of unsigned wrap-around and range bounds removes it, so this is an improvement. ---- 34 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/openjpeg2/openjpeg2_2.5.4.orig.tar.xz Result: main openjpeg-2.5.4/thirdparty/libz/compress.c:50:41: style: Condition 'sourceLen>(uLong)max' is always true [knownConditionTrueFalse] Explanation: `max` is `(uInt)-1`, which is UINT_MAX, and `sourceLen` is an unknown `uLong` parameter. Main treated `(uLong)max` as -1 instead of 4294967295 and so claimed `sourceLen > (uLong)max` is always true. That is wrong: on any platform the condition can be false (always false when uLong is 32-bit, depends on the value when it is 64-bit). The PR fixes the cast and conversion value handling (castValue, truncateValues), so this false positive is gone. The matching libpng `(uInt)-1` false positives in the same diff disappeared too. ---- 35 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/paho.mqtt.c/paho.mqtt.c_1.3.16+ds.orig.tar.xz Result: main eclipse-paho-paho.mqtt.c-b830b1d/src/Proxy.c:202:14: style: Condition 'curtok==NULL' is always false [knownConditionTrueFalse] Explanation: Inside `while (curtok)`, the check `curtok == NULL` at line 202 can never be true, so the warning is a true positive in both versions. The PR keeps the same warning and adds an error path pointing to the loop condition at line 195 that makes it always false. This matches the PR's test expectation changes, which add the originating condition to knownConditionTrueFalse messages. The message now explains the cause better, so it is a small improvement. ---- 36 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pgcopydb/pgcopydb_0.18.orig.tar.gz Result: your dimitri-pgcopydb-2591411/src/bin/pgcopydb/ld_transform.c:1143:11: style: Condition 'mesg==NULL' is always false [knownConditionTrueFalse] dimitri-pgcopydb-2591411/src/bin/pgcopydb/ld_transform.c:1140:25: note: Assignment 'mesg=&(privateContext->currentMsg)', assigned value is never 0 dimitri-pgcopydb-2591411/src/bin/pgcopydb/ld_transform.c:1143:11: note: Condition 'mesg==NULL' is always false Explanation: Both main and your report this warning. The only difference is that the PR's output now includes an error path (notes) for it. The finding itself is correct: mesg = &(privateContext->currentMsg) is the address of a struct member and can never be NULL, so 'mesg==NULL' is always false. The added note gives some context ('assigned value is never 0'), but the warning, its location and its meaning are unchanged, so this makes no material difference to users. ---- 37 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/pgmodeler/pgmodeler_2.0.0~beta.orig.tar.gz Result: main pgmodeler-2.0.0-beta/libs/libcore/src/operationlist.cpp:256:8: style: Condition 'tab' is always true [knownConditionTrueFalse] Explanation: At line 256, `tab` is always non-null. The `!tab ||` short-circuit at line 254 means the third operand is only evaluated when `tab` is non-null, so the warning itself is a true positive and is still reported. The only change is the message: the new output adds an error path pointing at the '!tab' condition on line 254, which explains why 'tab' is always true. The message became more informative, so this is a small improvement. ---- 38 / 50 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/p/pixman/pixman_0.46.4.orig.tar.gz Result: your pixman-0.46.4/test/utils/utils-prng.c:190:13: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: In the PROCESS_ONE_LANE macro, `int32_t mask_ff = (... ) & 0x80000000;` can only be 0 or 0x80000000. Converted to int32_t, 0x80000000 becomes INT_MIN, a negative value. The next line, `mask_ff >> 31` (and likewise `mask_00 >> 31`), then shifts that negative value right. The code relies on an arithmetic right shift to smear the sign bit into all ones. That is implementation-defined, so a portability warning is technically justified. Cppcheck's shiftNegativeLHS check covers `>>` as well, and the PR's improved signed/unsigned conversion tracking now carries the negative value through. The message wording ('undefined behaviour') overstates it for a right shift, but that is pre-existing message text. The finding is real non-portable code, though intentional and harmless on common targets. ---- 39 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/plast/plast_2.3.2+dfsg.orig.tar.xz Result: main plast_source_v2.3.2/src/launcher/observers/AbstractProgressionObserver.cpp:138:16: style: Condition 'e3!=0' is always true [knownConditionTrueFalse] Explanation: Line 138 repeats the check `e3 != 0` inside the block guarded by `if (e3 != 0)` on line 126, and `e3` is not changed in between. The warning is a true positive in both versions. Only the message changed: the PR adds an error path note pointing to the earlier condition at line 126. This explains why the condition is always true, so the message is more informative. ---- 40 / 50 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/scscp-imcce/scscp-imcce_1.0.3+ds.orig.tar.xz Result: main scscp-imcce-1.0.3+ds/tests/scscpservertest.c:539:21: style: Condition 'typeanswer==28' is always false [knownConditionTrueFalse] Explanation: The warning text is unchanged. The only difference is that the PR's version now carries an error path: a note at line 276 ('Assuming that condition typeanswer==28 is not redundant') leading to line 539. This comes from the PR's change in infer.cpp, where addToErrorPath now keeps the condition from the referenced values; the updated tests show the same pattern of added 'x -> y' paths. Pointing the user to the earlier check on typeanswer that makes this condition known makes the diagnostic easier to understand and verify. Line 276 is not shown, so I cannot confirm the warning itself is a true positive. As far as the shown code goes, the change only makes the existing message more informative. ---- 41 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sdlgfx/sdlgfx_2.0.25.orig.tar.gz Result: your sdlgfx-2.0.25/SDL_gfxPrimitives.c:2662:10: style: Condition 'dx!=0' is always true [knownConditionTrueFalse] sdlgfx-2.0.25/SDL_gfxPrimitives.c:2640:9: note: Assuming that condition 'dx==0' is not redundant sdlgfx-2.0.25/SDL_gfxPrimitives.c:2654:16: note: Assuming condition is true sdlgfx-2.0.25/SDL_gfxPrimitives.c:2658:7: note: Assuming condition is false sdlgfx-2.0.25/SDL_gfxPrimitives.c:2662:10: note: Condition 'dx!=0' is always true Explanation: Line 2662 is inside the `else if (dy == 0)` branch, which is reached only when `dx == 0` at line 2640 was false. `dx` is not changed in between, so `dx!=0` really is always true; both versions report this true positive. Main reported it with no supporting notes. The PR adds an error path that points to the `dx==0` check at line 2640 as the reason, which explains the warning better. The warning itself is unchanged, and the added path makes it more informative and easier to verify. ---- 42 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sight/sight_26.0.0.orig.tar.gz Result: your sight-26.0.0/3rd-party/minizip/mz_zip_rw.c:533:9: style: Condition 'algorithm' is always true [knownConditionTrueFalse] sight-26.0.0/3rd-party/minizip/mz_zip_rw.c:517:20: note: Assuming that condition '!algorithm' is not redundant sight-26.0.0/3rd-party/minizip/mz_zip_rw.c:521:9: note: Assuming condition is false sight-26.0.0/3rd-party/minizip/mz_zip_rw.c:533:9: note: Condition 'algorithm' is always true Explanation: The warning is correct in both versions. Line 517 returns early when `algorithm` is NULL, so the check `if (algorithm)` at line 533 is always true. The PR only changes the message: it now adds error-path notes pointing to the earlier `!algorithm` check at line 517. The note "Assuming condition is false" at line 521 is a bit noisy, but the added context makes the warning easier to understand. Since the PR intentionally adds such error paths (see the updated test expectations), this is a slightly more informative message. ---- 43 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/silo-llnl/silo-llnl_4.12.1.orig.tar.xz Result: your silo-llnl-4.12.1/tools/browser/func.c:1516:67: style: Condition 'target' is always true [knownConditionTrueFalse] silo-llnl-4.12.1/tools/browser/func.c:1515:25: note: Assuming that condition 'target' is not redundant silo-llnl-4.12.1/tools/browser/func.c:1516:67: note: Condition 'target' is always true Explanation: The warning is a true positive in both versions. At line 1516, `target?target:...` sits inside `if (target)` at line 1515, so `target` is always true there. The PR only adds an error-path note pointing to the guarding condition at line 1515. That makes the message more informative and easier to understand, so it is a small improvement in accuracy and usability. ---- 44 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/smalt/smalt_0.7.6.orig.tar.gz Result: main smalt-0.7.6/src/sequence.c:1448:28: style: Condition 'l> 8l`, where `w` is a signed INT16_T, to get the high byte, which is then cast to char. A right shift of a negative signed value is implementation-defined in C (C11 6.5.7p5), not undefined behaviour. So the claim "Shifting a negative value is technically undefined behaviour" is inaccurate here. The idiom is portable in practice, and the warning was noise for this byte-extraction code. The PR's value-flow and type changes evidently no longer produce a possible negative value for `w`. It is not clear that this was the deliberate reason, but dropping this warning benefits users. ---- 46 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/syncevolution/syncevolution_2.0.0.orig.tar.bz2 Result: your syncevolution-syncevolution-2-0-0/src/dbus/server/progress-data.cpp:183:39: error: Array 'm_syncProp[5]' accessed at index -2147483648, which is out of bounds. [negativeIndex] Explanation: The loop index starts at `(int)m_step + 1`, where `m_step` is a `ProgressStep` enum with small non-negative values (`PRO_SYNC_UNINIT`…`PRO_SYNC_TOTAL`). So `i - 1` is never negative, and certainly never INT_MIN. The reported index -2147483648 is not a real value. It comes from the new cast type-range bounds the PR adds for `(int)m_step`, which are now turned into concrete lower-bound values for `i` and `i - 1`. The PR's guard for non-negative induction variables does not apply here, because the init value has no non-negative lower bound. The new negativeIndex error is a false positive. ---- 47 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/u/unzip/unzip_6.0.orig.tar.gz Result: your unzip60/timezone.c:660:13: style: Condition 'ltm==(struct tm*)NULL' is always false [knownConditionTrueFalse] unzip60/timezone.c:574:17: note: Calling function 'gmtime' returns !0 unzip60/timezone.c:659:20: note: Calling function 'localtime' returns !0 unzip60/timezone.c:660:13: note: Condition 'ltm==(struct tm*)NULL' is always false Explanation: Both main and the PR report the same knownConditionTrueFalse warning at the same location with the same text. Only the attached notes differ: the PR shows an error path through the file's own localtime/gmtime replacements, which return pointers to static storage ("returns !0"). Main's notes are not shown, so it is impossible to tell whether the path became more or less informative. Whether the warning is right depends on those custom implementations, and that is unchanged by the PR. For users the reported diagnostic is effectively the same. ---- 48 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vimix/vimix_0.9.0+git20260228+ds.orig.tar.xz Result: main vimix-0.9.0+git20260228+ds/src/MediaPlayer.cpp:786:13: style: Condition 'effect' is always true [knownConditionTrueFalse] Explanation: The PR changes the warning's error path but not the warning itself. Main reports "Condition 'effect' is always true" with no explanation. Your version reports the same warning with notes pointing to the earlier check 'effect==NULL' that returns, which explains why the condition is always true. The warning is still a true positive: if effect were NULL, the earlier if returns, so at line 786 effect is non-null. A clearer message helps the user, so the removal of the main line combined with the added 'your' line is an improvement. ---- 49 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/y/yabasic/yabasic_2.92.1.orig.tar.gz Result: main yabasic-2.92.1/io.c:1496:31: style: Condition '!strcmp(name,"red")' is always false [knownConditionTrueFalse] Explanation: Line 1496 has `!strcmp(name, "red") || !strcmp(name, "red")`. The second operand repeats the first, so it can only be evaluated when the first was false, and it is then always false. The warning is a true positive in both versions; only the text changed. The new version adds an error path: a note pointing at the first `!strcmp(name,"red")` at column 7 as the origin of the inference. That location is the real reason the condition is always false. The message is more informative for the user and no less accurate, so this is a small improvement. ---- 50 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/y/yad/yad_7.2.orig.tar.xz Result: your yad-7.2/src/main.c:278:11: style: Condition 'mw' is always true [knownConditionTrueFalse] yad-7.2/src/main.c:274:7: note: Assuming that condition 'mw' is not redundant yad-7.2/src/main.c:278:11: note: Condition 'mw' is always true Explanation: The warning is a true positive in both versions. Inside the block guarded by `if (mw && options.data.expander)`, the nested `if (mw)` at line 278 is always true. The only change is that the message now carries an error path pointing to the guarding condition at line 274. This explains why the condition is always true, so the message is more informative and users can understand the redundancy more easily.