AI review of 2026-11-05_05-50-22-56f0fa953836-results.txt PR: #8819 https://github.com/cppcheck-opensource/cppcheck/pull/8819 Tested: 56f0fa9538364b54ba636bcbc6b63633581feae2 Merge base: a6d2c1777a0203cdbb8df60a70f7d49aeb57aa31 Reviewed: 2026-11-06 22:48:40 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 3829 in the report (random sample), 95 not reviewed: valueFlowMaxIterations Verdicts: 4 acceptable regression, 28 improvement, 18 neutral Tokens: 119898 input, 3042720 cache read, 760680 cache write, 17475 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/apngopt/apngopt_1.4.orig.tar.xz Result: main libpng/pngmem.c:140:32: warning:inconclusive: Either the condition 'old_elements<0' is redundant or there is signed integer overflow for expression '2147483647-old_elements'. [integerOverflowCond] libpng/pngmem.c:133:63: note: Assuming that condition 'old_elements<0' is not redundant libpng/pngmem.c:140:32: note: Integer overflow Explanation: `png_error` is noreturn, so on line 140 `old_elements` is >= 0 and `INT_MAX - old_elements` cannot overflow. Even if `old_elements` were negative, the old warning reasoned about the wrong path. It would come from the impossible upper bound (old_elements <= -1) taken from the `old_elements<0` condition, and that bound only means the value is >= 0. The warning was an inconclusive false positive. The PR's changes to how impossible range bounds are combined in arithmetic (the `-` inversion and the conversion handling) removed it. Removing this false positive is an improvement. ---- 2 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/atomes/atomes_1.3.1.orig.tar.gz Result: your atomes_1.3.1/src/calc/dl_poly/dlp_viz.c:952:35: style: Condition 'i!=4' is always true [knownConditionTrueFalse] atomes_1.3.1/src/calc/dl_poly/dlp_viz.c:947:19: note: Assuming that condition 'i==4' is not redundant atomes_1.3.1/src/calc/dl_poly/dlp_viz.c:952:35: note: Condition 'i!=4' is always true Explanation: Line 952 is the `else` of `if (forall || i == 4 || i == SEXTERN)`, so on that path `i == 4` is already known to be false and `i != 4` is always true. The condition is redundant, so the new knownConditionTrueFalse warning is a true positive. The note wording ('Assuming that condition i==4 is not redundant') is slightly awkward, but the finding is correct. ---- 3 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/byacc-j/byacc-j_1.15.orig.tar.gz Result: main byaccj1.15/src/reader.c:1131:50: style: Condition 'c!='_'' is always true [knownConditionTrueFalse] Explanation: Line 1131 tests `c != '_'` twice, so the second test is always true when it is reached. That is a real redundancy, and both versions report it. The PR keeps the same warning but adds note lines pointing to the earlier `c != '_'` check at column 26 as the reason. This is a more informative error path for the same true positive, so the change is a slight improvement in message accuracy. ---- 4 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/concalc/concalc_0.9.3.orig.tar.gz Result: main concalc-0.9.3/src/global.h:445:17: style: Condition 'line!=NULL' is always true [knownConditionTrueFalse] Explanation: The warning at line 445 is still reported. Only its text changed: the 'your' version adds an error path showing that the outer 'if(line!=NULL)' at line 439 makes the inner check always true. The warning is a true positive, because the inner 'else if(line!=NULL)' sits inside the outer 'if(line!=NULL)'. The new output adds more context and is no less accurate, so this is a minor improvement in message quality. ---- 5 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/cpu/cpu_1.4.3.orig.tar.gz Result: main cpu-1.4.3/src/main/cpu.c:95:16: style: Condition 'gmethod!=NULL' is always true [knownConditionTrueFalse] Explanation: The warning itself is correct in both versions. If gmethod is NULL the program exits at line 93, so 'gmethod != NULL' at line 95 is always true. The 'main' and 'your' lines have the same text; the only difference is that the new output adds notes. One note explains why the condition holds ('Assuming that condition ... is not redundant' at line 89). That gives users more useful context, so the message is slightly more informative. Strictly, the removed line is just the old form of the same true positive. ---- 6 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/d/dahdi-tools/dahdi-tools_3.4.0.orig.tar.gz Result: main dahdi-tools-3.4.0/xpp/xtalk/xtalk_base.c:78:17: style: Condition 'xproto' is always true [knownConditionTrueFalse] Explanation: The same warning appears on both sides at the same location with the same message. The only difference is that the 'your' entry carries notes, which is just how the diff output displays it. The warning itself is a true positive: '&xtalk_base->xproto' is the address of a struct member and is never null, so 'xproto' is always true. The PR leaves this warning effectively unchanged. ---- 7 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/d/deepin-qt5dxcb-plugin/deepin-qt5dxcb-plugin_5.7.12.orig.tar.gz Result: your qt5platform-plugins-5.7.12/src/ddesktopinputselectioncontrol.cpp:434:43: style: Condition 'm_anchorSelectionHandle' is always true [knownConditionTrueFalse] qt5platform-plugins-5.7.12/src/ddesktopinputselectioncontrol.cpp:434:16: note: Assuming that condition 'm_anchorSelectionHandle' is not redundant qt5platform-plugins-5.7.12/src/ddesktopinputselectioncontrol.cpp:434:43: note: Condition 'm_anchorSelectionHandle' is always true Explanation: Line 434 tests `m_anchorSelectionHandle && m_anchorSelectionHandle`, the same pointer twice (probably meant m_cursorSelectionHandle), so the second check really is always true. The warning was already reported by main and is still reported. The only difference is the added note chain ('Assuming that condition ... is not redundant'), which is accurate. The finding itself is unchanged. ---- 8 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/d/diamond-aligner/diamond-aligner_2.2.8.orig.tar.gz Result: your bbuchfink-diamond-745cd3b/src/lib/blast/blastn_score.cpp:1529:37: style: Condition 'alignmentScoreProbabilities!=NULL' is always true [knownConditionTrueFalse] bbuchfink-diamond-745cd3b/src/lib/blast/blastn_score.cpp:1450:37: note: Assuming that condition 'alignmentScoreProbabilities==NULL' is not redundant bbuchfink-diamond-745cd3b/src/lib/blast/blastn_score.cpp:1529:37: note: Condition 'alignmentScoreProbabilities!=NULL' is always true Explanation: Main and the PR report the same warning, with the same text, at the same location. Only the error-path notes differ. The PR's notes point to the earlier NULL check at line 1450, which presumably returns early when the allocation fails, so the later '!= NULL' check before sfree is indeed always true. The warning is a true positive in both versions. Main's notes are not shown, so neither version's notes can be judged more accurate, and the change does not matter to users. ---- 9 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/d/diffutils/diffutils_3.12.orig.tar.xz Result: your diffutils-3.12/lib/fnmatch_loop.c:925:38: style: Condition 'n!=string_end' is always true [knownConditionTrueFalse] diffutils-3.12/lib/fnmatch_loop.c:922:9: note: Assuming that condition 'n==string_end' is not redundant diffutils-3.12/lib/fnmatch_loop.c:925:38: note: Condition 'n!=string_end' is always true Explanation: Both main and the PR report this same warning. The only difference is that the PR version now carries extra notes ("Assuming that condition 'n==string_end' is not redundant"). The warning itself is correct: line 922 returns when n == string_end, so `n != string_end` on line 925 is always true. Nothing changes for users apart from how the message is shown, which is at most slightly more informative. ---- 10 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/d/ding-libs/ding-libs_0.7.0.orig.tar.xz Result: main ding-libs-0.7.0/dhash/dhash.c:709:15: style: Condition 'table!=NULL' is always true [knownConditionTrueFalse] Explanation: The function returns early when `table` is NULL (`if (!table) return HASH_ERROR_BAD_TABLE;`), so the later check `table != NULL` is always true. The warning is a true positive and is still reported. The only change is that the PR version now adds notes pointing at line 707, which shows where the earlier check is. The main-only line is therefore the same finding with a more detailed error path, which makes the output slightly more helpful. ---- 11 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/d/drawxtl/drawxtl_5.5.orig.tar.gz Result: main DRAWxtl/source/DRAWxtl55/DRAWxtl2.cxx:1491:30: style: Condition 'n==drvui->triple[0]' is always false [knownConditionTrueFalse] Explanation: Both versions report the same warning at 1491:30, and it is correct. Line 1472 does `continue` when `drvui->triple[0] == n`. Nothing between that check and line 1491 modifies `n` or `drvui->triple`, so `n == drvui->triple[0]` is always false there. The main line only reappears as a 'your' line, probably with a different error path. The 'your' notes point correctly at the condition on line 1472. The finding and its accuracy are unchanged, so this does not matter to users. ---- 12 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/fastfetch/fastfetch_2.69.0+dfsg.orig.tar.xz Result: main fastfetch-2.69.0/src/detection/gpu/gpu_windows.c:470:45: style: Condition 'options->driverSpecific' is always true [knownConditionTrueFalse] Explanation: The warning at line 470 was not removed. The PR only changed its text: it now carries error-path notes ('Assuming that condition ... is not redundant' at line 443). The same happened to all the sibling warnings. The warning itself is a true positive: inside the `if (options->driverSpecific && ...)` block, `options->driverSpecific` is always true. The new message explains why, which makes it more accurate and useful. ---- 13 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/ffms2/ffms2_5.0.orig.tar.xz Result: main FFMS-ffms2-7ed5e4d/src/avisynth/avisynth.cpp:53:33: style: Condition 'Index' is always true [knownConditionTrueFalse] Explanation: In `OverWrite || !Index || (Index && ...)`, the right operand is only evaluated when `!Index` is false, so `Index` is non-null there and the warning is a true positive. Both main and the PR report it at the same location with the same text. The only difference is that the new output adds error-path notes ('Assuming that condition '!Index' is not redundant'). That makes the message more informative, so this is a small improvement. ---- 14 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gluas/gluas_0.1.20.orig.tar.gz Result: main gluas-0.1.20/src/preview_layer.c:64:7: style: Condition 'layers' is always true [knownConditionTrueFalse] Explanation: The warning at line 64 is still reported. Only the extra 'note' lines (the error path) differ between the two versions. 'layers' is checked at line 50 and the function returns early if it is null, so 'if (layers)' at line 64 is always true. Both versions report the same true positive. The new output adds a note 'Assuming condition is false' at line 58, which is slightly odd but harmless. Users see the same warning, so the change is essentially neutral. ---- 15 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gssproxy/gssproxy_0.9.2.orig.tar.gz Result: main gssproxy-0.9.2/src/client/gpm_common.c:708:9: style: Condition '!gpmctx' is always false [knownConditionTrueFalse] Explanation: Both versions report the same knownConditionTrueFalse warning for `if (!gpmctx)` after `gpmctx = gpm_get_ctx();`. In gssproxy, `gpm_get_ctx()` returns the address of a static global context (`&gpm_global_ctx`), so it is never NULL and the warning is a true positive. The only difference is that the PR's output adds error-path notes ("Calling function 'gpm_get_ctx' returns !0"). These explain why the condition is always false, which makes the diagnostic more informative without changing its correctness. ---- 16 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/i/iat/iat_0.1.7.orig.tar.bz2 Result: main iat-0.1.7/src/convert_2_iso.c:293:18: style: Condition 'n_mode>-1' is always true [knownConditionTrueFalse] iat-0.1.7/src/convert_2_iso.c:292:15: note: Assignment 'n_mode=(char)(*header.msf_block.mode)', assigned value is greater than -1 iat-0.1.7/src/convert_2_iso.c:293:18: note: Condition 'n_mode>-1' is always true Explanation: `n_mode` is assigned `(char)*header.msf_block.mode`, a byte read from a file. Plain `char` is signed on common platforms such as x86 Linux, so a byte value of 0x80–0xFF becomes negative. That means `n_mode > -1` can be false, and the code's `else printf("Weird Mode")` branch handles exactly that case. Main's "always true" claim came from treating the cast result as non-negative, which is a false positive. The PR now handles plain-char casts according to their signedness and keeps both outcomes when signedness is unknown, which removes this FP. ---- 17 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/ijs/ijs_0.35.orig.tar.gz Result: your ijs-0.35/ijs_exec_win.c:148:12: style: Condition 'flag' is always true [knownConditionTrueFalse] ijs-0.35/ijs_exec_win.c:132:9: note: Assuming that condition 'flag' is not redundant ijs-0.35/ijs_exec_win.c:148:12: note: Condition 'flag' is always true Explanation: Both versions report the same warning at line 148, and it is correct. The else branch at line 137 always returns, so 'flag' must be nonzero when line 148 is reached, and 'flag ? 0 : -1' always takes the true branch. The only difference is the attached error path: the new output adds notes pointing to the 'if (flag)' at line 132. That gives some context, although the wording 'Assuming that condition is not redundant' is slightly misleading because the result is certain, not assumed. Location, severity, ID and message text are unchanged, so this does not matter much to users either way. ---- 18 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/j/jags/jags_5.0.1.orig.tar.gz Result: your JAGS-5.0.1/libltdl/slist.c:322:11: style: Condition '!right' is always false [knownConditionTrueFalse] JAGS-5.0.1/libltdl/slist.c:320:26: note: Assuming that condition 'right=right->next' is not redundant JAGS-5.0.1/libltdl/slist.c:322:11: note: Condition '!right' is always false Explanation: Both main and the PR report the same warning at slist.c:322; only the attached note/error path differs. The warning is a true positive: the loop condition `while (right && (right = right->next))` guarantees `right` is non-null inside the body, so `!right` on line 322 is always false. The PR's note, which points at the loop condition `right=right->next`, is a correct explanation. The diagnostic itself is unchanged, so this does not matter to users either way. ---- 19 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/k/kile/kile_2.9.94.orig.tar.bz2 Result: main kile-2.9.94/src/editorextension.cpp:3470:9: style: Condition 'view' is always true [knownConditionTrueFalse] Explanation: The warning is still a true positive: after `if(!view) return;`, the check `view &&` on line 3470 is redundant. The main and your lines are identical, and the your line now carries notes that point to the early-return check on line 3465. The same pattern shows up across the other entries for this package, so the change looks like the error path / message becoming more informative. At worst it is neutral, since the warning text itself is unchanged and still correct. ---- 20 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libg/libghemical/libghemical_3.0.0.orig.tar.gz Result: main libghemical-3.0.0/src/eng1_sf.cpp:1447:40: style: Condition '(indr1-3)>=0' is always false [knownConditionTrueFalse] libghemical-3.0.0/src/eng1_sf.cpp:1446:40: note: Assuming that condition '(indr1-2)>=0' is not redundant libghemical-3.0.0/src/eng1_sf.cpp:1447:40: note: Condition '(indr1-3)>=0' is always false Explanation: Line 1446 is a separate `if` that only sets `h4flag_2`. Both of its branches reach line 1447, so `indr1` is not constrained there. `indr1` is a residue index that can be 3 or larger, which makes `(indr1-3)>=0` true. Main's 'always false' warning came from wrongly carrying the `indr1-2 < 0` assumption past the `if`. It was a false positive, and the PR removes it. ---- 21 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libg/libghemical/libghemical_3.0.0.orig.tar.gz Result: your libghemical-3.0.0/src/eng1_mm_default.cpp:394:18: style: Condition 'tp!=NULL' is always true [knownConditionTrueFalse] libghemical-3.0.0/src/eng1_mm_default.cpp:394:7: note: Assuming that condition '!tp' is not redundant libghemical-3.0.0/src/eng1_mm_default.cpp:394:18: note: Condition 'tp!=NULL' is always true Explanation: In `!tp || (tp != NULL && ...)`, the right side of `||` is only evaluated when `tp` is non-null, so `tp != NULL` is indeed always true. Both main and the PR report this warning at the same location. The PR output adds notes explaining the reasoning ('Assuming that condition '!tp' is not redundant'), which makes the message more informative. The warning remains a true positive, and the clearer explanation is a small improvement. ---- 22 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libg/libgphoto2/libgphoto2_2.5.34.orig.tar.xz Result: main libgphoto2-2.5.34/camlibs/ptp2/library.c:4392:17: style: Condition 'done!=3' is always true [knownConditionTrueFalse] Explanation: The warning is a true positive. If `done == 3`, the loop already exits through `break` at line 4383, so `done != 3` in the while condition is always true. The PR keeps the same warning and adds an error path ('Assuming that condition done==3 is not redundant'). That path explains exactly why the condition is always true, so the message is more helpful. ---- 23 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libh/libhbalinux/libhbalinux_1.0.16.orig.tar.gz Result: main libhbalinux-1.0.16/lport.c:317:11: style: Condition 'cp' is always true [knownConditionTrueFalse] Explanation: The warning itself is unchanged. 'cp' is always non-null at line 317 because the loop breaks when '!cp', so the true positive stays. The only difference is that the new output adds an error path: it notes that the condition '!cp' at line 309 is assumed not redundant. That explains to the user why 'cp' is always true, so the message became more informative. The main line and the your line are the same warning, with the your version carrying better context. ---- 24 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libm/libmems/libmems_1.6.0+4725.orig.tar.xz Result: your libmems-1.6.0+4725/libMems/Aligner.cpp:1699:39: warning: Either the condition 'right_adj==adjacencies.size()' is redundant or 'right_adj' can have the value adjacencies.size(). Expression 'adjacencies[right_adj]' causes access out of bounds. [containerOutOfBounds] libmems-1.6.0+4725/libMems/Aligner.cpp:1697:19: note: Assuming that condition 'right_adj==adjacencies.size()' is not redundant libmems-1.6.0+4725/libMems/Aligner.cpp:1699:39: note: Access out of bounds Explanation: In the debug branch, line 1697 explicitly checks `right_adj == adjacencies.size()` and treats it as a possible error, but only prints a message and continues. Line 1699 then indexes `adjacencies[right_adj]`, guarded only by `right_adj != -1`. If the case checked at 1697 happens, that access is out of bounds. The non-debug code at line 1704 does add the `!= adjacencies.size()` guard, which confirms the developers considered this value possible. The new warning is a valid 'condition redundant or out of bounds' finding. It was probably exposed by the PR's better handling of the unsigned-vs-`-1` comparison. ---- 25 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libx/libxtrx/libxtrx_0.0.1+git20191219.98458ce.orig.tar.xz Result: main libxtrx-0.0.1+git20191219.98458ce/xtrx.c:849:24: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] libxtrx-0.0.1+git20191219.98458ce/xtrx.c:842:34: note: Calling function 'xtrx_set_antenna_ex', 2nd argument 'XTRX_CH_ALL' value is -1 libxtrx-0.0.1+git20191219.98458ce/xtrx.c:849:24: note: Shifting a negative value is technically undefined behaviour Explanation: In libxtrx, `XTRX_CH_ALL` is defined in the `xtrx_channel_t` enum as `~0U`, not as a negative int. GCC therefore gives the enum an unsigned underlying type, so `ch` holds 0xFFFFFFFF. `ch >> (2*devnum)` is then a shift of an unsigned value, which is well defined. Main reported the value as -1 because it truncated `~0U` to a signed int. The shiftNegativeLHS warning was a false positive, and the PR's stricter handling of integer conversions drops that bogus negative value. The confidence is medium because the enum definition is recalled from the library's header, not shown in the provided source. ---- 26 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libz/libzeem/libzeem_2.1.2+dfsg.orig.tar.xz Result: main zeem-2.1.2/src/parser.cpp:278:32: style: Comparing expression of type 'char' against value 187. Condition is always false. [compareValueOutOfTypeRangeError] Explanation: The code compares `ch2 == static_cast(0xbb)`. Both sides are char, so `static_cast(0xbb)` is the same char value that ch2 holds when the byte is 0xBB, whatever the signedness of char. The comparison can be true, so main's 'always false' report was a false positive. Main used the unconverted value 187 instead of the value after the char cast. The PR now truncates cast values correctly and handles plain char with unknown sign, which removes this false positive. ---- 27 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/msolve/msolve_0.11.0.orig.tar.gz Result: your msolve-0.11.0/src/msolve/msolve.c:224:17: style: Condition 'gens->field_char' is always true [knownConditionTrueFalse] msolve-0.11.0/src/msolve/msolve.c:220:11: note: Assuming that condition 'gens->field_char' is not redundant msolve-0.11.0/src/msolve/msolve.c:221:27: note: Assuming condition is true msolve-0.11.0/src/msolve/msolve.c:224:17: note: Condition 'gens->field_char' is always true Explanation: Inside `if (gens->field_char)` at line 220, the inner `if (gens->field_char)` at line 224 is redundant: nothing in between (fprintf, loop, pointer check) changes gens->field_char. So the warning is a true positive. Both main and your report it; only the message changed, and the new version adds notes pointing to line 220 as the reason. Same finding with a better error path, so this is a slight improvement. ---- 28 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/netplan.io/netplan.io_1.2.2.orig.tar.gz Result: main netplan-1.2.2/src/validation.c:159:20: style: Condition 'host' is always true [knownConditionTrueFalse] Explanation: At line 159 the code is in the else branch of `if (!host)`, so `host` is non-null there and the warning is a true positive. The warning is still reported. It is reported again with an error path ('Assuming that condition !host is not redundant'). The main line differs from the your line only in that added note. A message with supporting notes is more informative, so the change is a small improvement. ---- 29 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nqptp/nqptp_1.2.6.orig.tar.gz Result: main nqptp-1.2.6/nqptp-message-handlers.c:125:31: style: Condition 'command==NULL' is always false [knownConditionTrueFalse] Explanation: The warning at line 125:31 is reported by both main and the PR. Only the companion line differs: the note text shown with the 'your' line is unchanged in content, so the main and your lines describe the same finding. The condition 'command==NULL' really is always false there: line 72 already checks command!=NULL, and strcmp(command, ...) is called on it earlier in the else-if chain. The diff entry most likely comes from a change in error path or ordering details, not from a change in the warning itself. This makes no difference to users. ---- 30 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nqptp/nqptp_1.2.6.orig.tar.gz Result: your nqptp-1.2.6/nqptp-message-handlers.c:125:31: style: Condition 'command==NULL' is always false [knownConditionTrueFalse] nqptp-1.2.6/nqptp-message-handlers.c:72:21: note: Assuming that condition 'command!=NULL' is not redundant nqptp-1.2.6/nqptp-message-handlers.c:125:31: note: Condition 'command==NULL' is always false Explanation: Main and the PR report the same warning at the same location with the same text. The only difference is in the notes: the PR's output includes the note 'Assuming that condition command!=NULL is not redundant' at line 72, which we cannot tell main had. The warning is a true positive either way. Line 72 checks command!=NULL, and the earlier else-if branches already call strcmp(command, ...), so the command==NULL test at line 125 can never be true. The change is only cosmetic to the error path. ---- 31 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nx-libs/nx-libs_3.5.99.27.orig.tar.gz Result: main nx-libs-3.5.99.27/nx-X11/programs/Xserver/xkb/XKBGAlloc.c:117:6: style: Condition '*elems' is always true [knownConditionTrueFalse] Explanation: The PR did not remove this warning. The same 'Condition '*elems' is always true' warning at XKBGAlloc.c:117:6 is still reported by the PR build; only its note/error-path lines differ. The warning itself is valid: line 104 returns when *elems is NULL, so the check at line 117 is redundant. Users see the same diagnostic, so the change does not matter. ---- 32 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/openssh/openssh_10.6p2.orig.tar.xz Result: your openssh-10.6p2/regress/unittests/match/tests.c:39:36: style: Condition '*pattern!='*'' is always true [knownConditionTrueFalse] openssh-10.6p2/regress/unittests/match/tests.c:31:20: note: Assuming that condition '*pattern=='*'' is not redundant openssh-10.6p2/regress/unittests/match/tests.c:35:8: note: Assuming condition is false openssh-10.6p2/regress/unittests/match/tests.c:39:36: note: Condition '*pattern!='*'' is always true Explanation: After the loop `while (*pattern == '*') pattern++;` ends, `*pattern` cannot be '*', so `*pattern != '*'` on line 39 really is always true. This is a true positive in both versions. Main reported it with no path information. The PR now attaches an error path: the loop condition at line 31 and the `!*pattern` check at line 35. That explains why the condition is always true, so the message is more informative. The warning itself is unchanged. ---- 33 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/paml/paml_4.10.10+dfsg.orig.tar.xz Result: main abacus-gene-paml-4c7902f/src/tools.c:1423:15: style: Condition 'z_rndu==0' is always false [knownConditionTrueFalse] abacus-gene-paml-4c7902f/src/tools.c:1422:28: note: Assignment 'z_rndu=z_rndu*69069+1', assigned value is greater than 0 abacus-gene-paml-4c7902f/src/tools.c:1423:15: note: Condition 'z_rndu==0' is always false Explanation: z_rndu is an unsigned int. `z_rndu * 69069 + 1` wraps modulo 2^32, so it can be 0, for example when z_rndu*69069 == 0xFFFFFFFF. The old reasoning that the assigned value is greater than 0 ignored unsigned wraparound. The PR stops range bounds from propagating through unsigned arithmetic that may wrap, so this false positive is gone. ---- 34 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pcb/pcb_4.2.2.orig.tar.gz Result: your pcb-4.2.2/src/action.c:7185:12: style: Condition 'e' is always true [knownConditionTrueFalse] pcb-4.2.2/src/action.c:7143:7: note: Assuming that condition '!e' is not redundant pcb-4.2.2/src/action.c:7185:12: note: Condition 'e' is always true Explanation: Main reported the same warning at the same location. The only difference is that the new output also shows notes: line 7143 `if (!e)` is followed by `else if (e && ...)`, so `e` is always true in the else branch. The warning itself is unchanged and is a true positive. The added notes give the same information as before and do not make the message more or less accurate. ---- 35 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pdlzip/pdlzip_1.15.orig.tar.xz Result: main pdlzip-1.15/LzmaEnc.c:1375:33: style: Condition 'out_size>0' is always true [knownConditionTrueFalse] pdlzip-1.15/LzmaEnc.c:1374:67: note: Assignment 'out_size=p->rc.processed+Lh_size+Lt_size', assigned value is greater than 25 pdlzip-1.15/LzmaEnc.c:1375:33: note: Condition 'out_size>0' is always true Explanation: `out_size` is `p->rc.processed + Lh_size + Lt_size`. Lh_size and Lt_size are positive constants (6 and 20 in lzip), and `processed` is a byte counter. So `out_size > 0` is always true in practice, and main's warning was effectively a true positive (a redundant defensive check). The PR now refuses to derive lower bounds from unsigned additions it cannot prove free of wraparound. The sum is unsigned 64-bit, so a wrap is theoretically possible, and the warning disappears. This loses a correct but low-value style finding for the sake of soundness, which makes it a new false negative rather than a fixed false positive. ---- 36 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pldebugger/pldebugger_1.10.orig.tar.gz Result: main pldebugger-1.10/plpgsql_debugger.c:1115:7: style: Condition 'target' is always true [knownConditionTrueFalse] Explanation: The same warning is reported at the same location by both versions. Only the extra note lines differ: the new version adds an 'Assuming that condition !target is not redundant' note at line 1073. This is the usual pattern where an earlier `if (!target) return` makes the later `if (target)` always true. Whether the warning is valid does not change. The added error-path information is a small presentational change at most, so it is neutral for users. ---- 37 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/progressivemauve/progressivemauve_1.2.0+4713+dfsg.orig.tar.xz Result: main mauvealigner-1.2.0+4713/src/stripSubsetLCBs.cpp:123:22: style: Condition 'min_genome_count==-1' is always false [knownConditionTrueFalse] Explanation: `min_genome_count` is very likely initialised to the sentinel -1 (probably in an unsigned variable) and only overwritten from argv when an optional argument is given; the declaration is not shown. With an unsigned variable, `min_genome_count == -1` converts -1 to the type's maximum, so the check is true exactly when the default was kept. The condition depends on the command line, so 'always false' was a false positive. It most likely came from main mishandling the signed/unsigned conversion of the sentinel, which this PR rewrites, so removing it is an improvement. ---- 38 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/python-espeak/python-espeak_0.5.orig.tar.gz Result: main python-espeak-0.5/espeak/espeakmodulecore.cpp:124:10: style: Condition 'len>0' is always true [knownConditionTrueFalse] python-espeak-0.5/espeak/espeakmodulecore.cpp:122:28: note: Assignment 'len=strlen(text)+1', assigned value is greater than 0 python-espeak-0.5/espeak/espeakmodulecore.cpp:124:10: note: Condition 'len>0' is always true Explanation: `len = strlen(text) + 1` is a `size_t`. In practice it is always at least 1: `strlen` cannot return SIZE_MAX, because no object can be that large, so `+1` never wraps. The check `len > 0` is therefore always true and the else branch is dead code, so the removed warning was a true positive. The PR now treats unsigned `+` as possibly wrapping and no longer infers the lower bound. That is more conservative but loses a valid finding, a new false negative. ---- 39 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/python-espeak/python-espeak_0.5.orig.tar.gz Result: your python-espeak-0.5/espeak/espeakmodulecore.cpp:379:31: style: Comparing expression of type 'bool' against value -1. Condition is always false. [compareValueOutOfTypeRangeError] Explanation: Cppcheck reports the type of `pyespeak_initialize()` as `bool`, which comes from its declared return type. A bool promotes to 0 or 1, so `== -1` can never be true. That means the initialization-failure branch is dead code, which is a real bug. The old check treated a 1-bit bool's minimum as -1 (it did not handle signedness for bool), so it missed this case. The new range logic correctly treats bool as [0,1]. The function definition is not shown, so confidence is medium. ---- 40 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/r/r-cran-zip/r-cran-zip_3.0.2.orig.tar.gz Result: main zip/src/unixutils.c:91:13: style: Condition '*size==-1' is always false [knownConditionTrueFalse] Explanation: `*size` is an `mz_uint64` (unsigned 64-bit). When `ftello` fails it returns -1, which is stored as ULLONG_MAX. In `*size == -1`, the -1 is also converted to ULLONG_MAX, so the comparison is true on error. The check works as intended. Main wrongly reported it as always false, probably by treating the unsigned value as non-negative without applying the usual arithmetic conversion. The PR adds proper common-type and unsigned-conversion handling, so removing this false positive is an improvement. ---- 41 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/rxp/rxp_1.5.0.orig.tar.gz Result: main rxp-1.5.0/src/url.c:447:9: style: Condition 'f' is always true [knownConditionTrueFalse] Explanation: Both main and the PR report the same warning, 'Condition 'f' is always true', at url.c:447. Only the attached note lines differ. After `if(!f) return f;` at line 413, `f` is non-null at line 447 when HAVE_LIBZ is not defined, so the warning is valid either way. The removed main line is just the counterpart of the re-emitted 'your' line, so users see no real difference. ---- 42 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/schism/schism_20261102.orig.tar.gz Result: main schismtracker-20261102/schism/widget-keyhandler.c:210:6: style: Condition '!widget' is always false [knownConditionTrueFalse] Explanation: The `main` line is the same warning as the `your` line at 210:6. Only the ordering or the attached notes differ, which shows up as a removed line plus an added line. The warning itself is a true positive: `&ACTIVE_WIDGET` is the address of an object, so it is never null and `!widget` is always false. The PR does not change the reported warning, so this has no effect on users. ---- 43 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/spice-gtk/spice-gtk_0.42.orig.tar.xz Result: main spice-gtk-0.42/src/spice-util.c:334:20: style: Condition 'length<0' is always false [knownConditionTrueFalse] spice-gtk-0.42/src/spice-util.c:333:26: note: Calling function 'get_line' returns !<=-1 spice-gtk-0.42/src/spice-util.c:334:20: note: Condition 'length<0' is always false Explanation: `get_line()` stores its result in a `gsize` (unsigned) `len`. It returns either the passed-in `len - i`, which is positive because `i < len`, or `p - str`, which is non-negative. So `length < 0` really can never be true here, and main's warning was technically correct, if only about defensive code. The PR stops carrying an impossible '<= -1' bound through an unsigned-to-signed conversion of the same size. In general such a conversion can produce negative values, so the PR is more conservative and loses this true positive. That makes it a new false negative, not a new false positive. ---- 44 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/stress-ng/stress-ng_0.22.02.orig.tar.xz Result: main stress-ng-0.22.02/core-shim.c:1641:12: style: Condition 'ret>=0' is always false [knownConditionTrueFalse] stress-ng-0.22.02/core-shim.c:1639:27: note: Calling function 'shim_enosys' returns -1 stress-ng-0.22.02/core-shim.c:1639:9: note: Assignment 'ret=(pid_t)shim_enosys(0,pid,wstatus,options)', assigned value is -1 stress-ng-0.22.02/core-shim.c:1641:12: note: Condition 'ret>=0' is always false Explanation: In the `#else` configuration, `ret` is assigned `(pid_t)shim_enosys(...)`. Cppcheck's own note says `shim_enosys` returns -1. `pid_t` is a signed type, so the cast keeps -1 and `ret >= 0` is indeed always false in that build configuration. The warning is technically correct, although it is a configuration-dependent stub. The PR rewrote cast/conversion value propagation and no longer carries the known value through the `(pid_t)` cast. That drops a true positive, i.e. a new false negative rather than a fixed false positive. ---- 45 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/tiptop/tiptop_2.3.2.orig.tar.gz Result: main tiptop-2.3.2/src/hash.c:143:9: style: Condition 'ptr' is always true [knownConditionTrueFalse] Explanation: The PR did not drop this warning. Main and your both report the same knownConditionTrueFalse at hash.c:143:9; the 'main' line is one half of a pair, and the 'your' line differs only in its attached notes. The warning is correct: inside 'while (ptr)', the inner check 'ptr &&' is always true. Only the supporting notes changed, which makes no meaningful difference to users. ---- 46 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/u/uxplay/uxplay_1.73.7.orig.tar.gz Result: main UxPlay-1.73.7/lib/srp.c:219:9: style: Condition '!ng' is always false [knownConditionTrueFalse] Explanation: The warning is still reported. The PR only changed its form: main printed a bare warning, and the PR version adds the error path explaining why. The code checks `if (!ng)` and calls exit(1), so at line 219 `!ng` really is always false. The warning stays a true positive, and the added notes ('Assuming that condition '!ng' is not redundant' at line 212) make it more informative. This is a minor message improvement. ---- 47 / 50 ---- Verdict: NEUTRAL (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 did not drop this warning. The same message, 'Condition effect is always true' at 786:13, is still reported on the 'your' side, so this pair only reflects a change in the error-path notes. The warning is a true positive: `effect` is non-null at line 786, because the earlier `if (effect == NULL || error != NULL)` branch returns. The new notes ('Assuming that condition effect==NULL is not redundant' → 'Condition effect is always true') are reasonable. Users still get the same correct finding, so this does not matter either way. ---- 48 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/w/watchcatd/watchcatd_1.2.1.orig.tar.gz Result: main watchcatd-1.2.1/slave.c:118:15: style: Condition 'r==-1' is always false [knownConditionTrueFalse] Explanation: `r` is a `size_t`. In `r == -1`, the `-1` is converted to SIZE_MAX, so the comparison is true whenever write() returns -1 and the result is stored in `r`. The condition is therefore not always false. Main's warning was a false positive, most likely from the old code assuming an unsigned value can never equal the literal -1 without applying the usual arithmetic conversions. The PR now handles the implicit conversion correctly, and removing this false positive is an improvement. ---- 49 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/x/xdvik-ja/xdvik-ja_22.87.06+j1.42.orig.tar.xz Result: main xdvik-ja-22.87.06+j1.42/texk/xdvik/gui/pagesel.c:1432:36: style: Condition '!(curr_idx==bot_visible)' is always true [knownConditionTrueFalse] Explanation: The same knownConditionTrueFalse warning at pagesel.c:1432 is reported by both main and the PR; only the accompanying error path differs. The PR version adds the note 'Assuming that condition curr_idx==top_visible is not redundant'. In the non-Motif build, top_visible and bot_visible appear never to be updated in the code shown, so they are presumably equal (e.g. both 0). Then once curr_idx != top_visible, the check !(curr_idx==bot_visible) is indeed always true. The warning is plausible in both versions and only its supporting notes changed, so this does not materially matter to users. ---- 50 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/x/xwax/xwax_1.10~beta1.orig.tar.gz Result: main xwax-1.10-beta1/rig.c:148:23: style: Condition 'z==-1' is always false [knownConditionTrueFalse] Explanation: `z` is a `size_t` assigned from `read()`, which returns `ssize_t`. In `z == -1`, the `-1` is converted to `SIZE_MAX`. If `read()` returns -1, `z` becomes `SIZE_MAX`, so the comparison is true. The condition can therefore be true at runtime, and main's 'always false' warning was a false positive, most likely from mishandling the signed-to-unsigned conversion of -1. The PR's more careful implicit-conversion handling removes it.