AI review of 2026-10-31_16-13-22-5c412fe0be60-results.txt PR: #8819 https://github.com/cppcheck-opensource/cppcheck/pull/8819 Tested: 5c412fe0be608afa3b800655002f459dc588522d Merge base: d9a02a9ee51d0f5c6d8fd52994c540dd81a83fd8 Reviewed: 2026-11-02 15:41:53 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 3942 in the report (random sample), 242 not reviewed: valueFlowMaxIterations Verdicts: 18 improvement, 28 neutral, 4 regression Tokens: 137873 input, 3724441 cache read, 76009 cache write, 22437 output The verdicts are written by AI and can be wrong. ---- 1 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/afterstep/afterstep_2.2.12.orig.tar.bz2 Result: main afterstep-devel-2.2.12/libAfterImage/bmp.c:286:6: style: Condition 'xim' is always true [knownConditionTrueFalse] Explanation: The same warning appears in main and in your. Only the extra note lines differ, which is why it shows up as a main/your pair. The warning is correct: xim==NULL returns early at line 280, so `if (xim)` at line 286 is always true. The new output adds the 'Assuming that condition xim==NULL is not redundant' note. That is a minor presentation difference with no real effect for users. ---- 2 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/a/apngasm/apngasm_2.91.orig.tar.gz Result: main apngasm-2.91/libpng/pngmem.c:143:32: warning:inconclusive: Either the condition 'old_elements<0' is redundant or there is signed integer overflow for expression '2147483647-old_elements'. [integerOverflowCond] apngasm-2.91/libpng/pngmem.c:136:63: note: Assuming that condition 'old_elements<0' is not redundant apngasm-2.91/libpng/pngmem.c:143:32: note: Integer overflow Explanation: Line 136 calls png_error() whenever old_elements < 0, and png_error does not return (libpng declares it PNG_NORETURN). So at line 143 old_elements is always >= 0, and INT_MAX - old_elements cannot overflow. The removed inconclusive integerOverflowCond warning was a false positive, so dropping it is an improvement. The new valueFlowMaxIterations debug line in png.c is a separate result and not judged here. ---- 3 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/a/avogadro/avogadro_2.0.0.orig.tar.gz Result: main OpenChemistry-avogadroapp-3ced952/avogadro/mainwindow.cpp:483:7: style: Condition 'pipeline' is always true [knownConditionTrueFalse] Explanation: The same warning is still reported at the same location with the same message. Only the main line appears on its own; the other paired main/your lines differ only in their notes or error path. The diff for this line is most likely a change in its note text, possibly a note being dropped. The warning itself is correct either way: the address of a reference returned by solidPipeline() is never null. This is not a meaningful change for users. ---- 4 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/briquolo/briquolo_0.5.7.orig.tar.gz Result: your briquolo-0.5.7/src/MOGL/MOGL_Fenetre.cpp:226:24: style: Condition 'vidInf==NULL' is always false [knownConditionTrueFalse] briquolo-0.5.7/src/MOGL/MOGL_Fenetre.cpp:221:24: note: Assuming that condition 'vidInf==NULL' is not redundant briquolo-0.5.7/src/MOGL/MOGL_Fenetre.cpp:226:24: note: Condition 'vidInf==NULL' is always false Explanation: The warning at line 226 is a true positive. vidInf was already checked against NULL at line 221, with an early return, so the second check at line 226 is always false. Main reported this as a plain one-line warning. The PR version reports the same warning with an error path pointing back to the earlier condition at line 221. The finding is unchanged and the message now explains why, so this is a small improvement (or at worst neutral). ---- 5 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/c/cal3d/cal3d_0.11.0.orig.tar.gz Result: your cal3d-0.11.0/src/cal3d/loader.cpp:1450:6: style: Condition '!rotation' is always false [knownConditionTrueFalse] cal3d-0.11.0/src/cal3d/loader.cpp:1422:6: note: Assuming that condition '!rotation' is not redundant cal3d-0.11.0/src/cal3d/loader.cpp:1431:6: note: Assuming condition is false cal3d-0.11.0/src/cal3d/loader.cpp:1437:6: note: Assuming condition is false cal3d-0.11.0/src/cal3d/loader.cpp:1450:6: note: Condition '!rotation' is always false Explanation: The warning itself is a true positive and is unchanged. `rotation` is null-checked and returned on at line 1422, so `!rotation` at 1450 is always false; the author meant to check `translationBoneSpace`. Only the error path differs. The new path adds 'Assuming condition is false' notes at 1431 (`!node`) and 1437 (`!rotationdata`). Neither condition constrains `rotation`, so the notes are irrelevant noise. That makes the explanation less accurate than main's. Main's exact notes are not shown, hence the low confidence. ---- 6 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/ccze/ccze_0.2.1.orig.tar.gz Result: your ccze-0.2.1/src/ccze-compat.c:397:20: style: Condition '*lineptr==NULL' is always false [knownConditionTrueFalse] ccze-0.2.1/src/ccze-compat.c:60:13: note: Assuming that condition 'value==0' is not redundant ccze-0.2.1/src/ccze-compat.c:396:31: note: Calling function 'ccze_realloc' returns !0 ccze-0.2.1/src/ccze-compat.c:397:20: note: Condition '*lineptr==NULL' is always false Explanation: Both main and the PR report the same warning at 397:20 with the same text; only the accompanying note/error-path lines appear to differ. The warning is plausible: ccze_realloc checks `value==0` at line 60 and apparently aborts on failure, so `*lineptr==NULL` after the call can never be true. The same main/your pairing appears for every other warning in this file, so this is a cosmetic change in reporting, not a gained or lost diagnosis. ---- 7 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/d/denemo/denemo_2.6.49.orig.tar.xz Result: main denemo-2.6.49/src/command/lilydirectives.c:854:17: style: Condition 'curheader==NULL' is always false [knownConditionTrueFalse] Explanation: The warning is not really removed. It appears as a 'main' line and an identical 'your' line, so only the extra info/notes differ. get_header() returns the address of a struct member (&Denemo.project->movement->header), which can never be NULL, so 'curheader==NULL' is always false in both versions. The warning text and location are the same; any change is only in the attached error path notes, which does not matter to users. ---- 8 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/e/ecdsautils/ecdsautils_0.4.2.orig.tar.gz Result: main freifunk-gluon-ecdsautils-69cee66/src/cli/hexutil.c:49:11: style: Condition 'len!=-1' is always true [knownConditionTrueFalse] Explanation: `len` is a `size_t`, so `-1` converts to SIZE_MAX. When the `while (len--)` loop runs to completion, the post-decrement at 0 wraps `len` to SIZE_MAX, which makes `len != -1` false. It is true only when the loop exits through `break` after a failed `sscanf`. The condition therefore really depends on the input and is not always true. Main's warning was a false positive caused by mishandling the signed-to-unsigned conversion and the unsigned wrap. The PR reworks implicit integral conversions and unsigned wrap handling, which removes this false positive. ---- 9 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/e/eukleides/eukleides_1.5.5.orig.tar.gz Result: your eukleides-1.5.5/src/common/interactive.c:52:28: warning: Either the condition '*c>'Z'' is redundant or the array 'strokes[26][2]' is accessed at index strokes[26][1], which is out of bounds. [arrayIndexOutOfBoundsCond] eukleides-1.5.5/src/common/interactive.c:46:21: note: Assuming that condition '*c>'Z'' is not redundant eukleides-1.5.5/src/common/interactive.c:48:6: note: Assignment 'i=(int)(*c-'A')', assigned value is 26 eukleides-1.5.5/src/common/interactive.c:44:18: note: Assuming condition is true eukleides-1.5.5/src/common/interactive.c:52:28: note: Array index out of bounds Explanation: Line 46 rejects any `*c` outside 'A'..'Z' by calling `runtime_error("invalid state")`. This is eukleides' fatal error routine, which almost certainly does not return (it exits or longjmps). So index 26 is not reachable on line 52. Cppcheck cannot see that `runtime_error` is noreturn because it is defined in another file, so it assumes execution continues after the error call. The new arrayIndexOutOfBoundsCond warning comes from the PR's changed char/integer value propagation, but it is a false positive in this context. ---- 10 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/f/fricas/fricas_1.3.13.orig.tar.bz2 Result: main fricas-1.3.13/src/hyper/htadd.c:500:15: style: Condition 'db_fp!=NULL' is always true [knownConditionTrueFalse] Explanation: The warning at htadd.c:500 appears in both main and your with identical text. Only the diff line pairing shows it as removed and re-added; it was not actually removed. The warning is a correct true positive: db_fp was checked for NULL at line 489 and the function returned early. Nothing changes for users. ---- 11 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/gegl/gegl_0.4.72.orig.tar.xz Result: main gegl-0.4.72/operations/generated/darken.c:99:10: style: Condition 'input' is always true [knownConditionTrueFalse] Explanation: The warning is reported by both versions. Main's message had no notes; the PR's message adds the notes 'Assuming that condition '!input' is not redundant' at line 88 and 'Condition 'input' is always true' at line 99. The finding is correct: if input is NULL, the branch at line 88 returns, so 'input' is always non-null at line 99. Same diagnostic at the same location, so the change does not matter to users. ---- 12 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gentle/gentle_1.9.5~alpha2+dfsg1.orig.tar.xz Result: main gentle-m-1.9.5.alpha2/src/SequenceCanvas.cpp:1208:28: style: Condition 'ama->pc' is always true [knownConditionTrueFalse] Explanation: Both main and the PR report the same warning, 'ama->pc' is always true at line 1208. Only the error-path notes differ. The warning is a true positive: line 1208 sits inside `if ( ama->pc && ama->curDisplay == ama->pc )`, so `ama->pc` must be non-null there. The PR's notes correctly point at line 1205 as the source. The warning, its location and its correctness are unchanged, so this makes no practical difference to users. ---- 13 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/glhack/glhack_1.2.orig.tar.gz Result: your glhack-1.2/tools/edtile/z_hsv.cpp:162:20: error: Signed integer overflow for expression 'seed>>4'. [integerOverflow] glhack-1.2/tools/edtile/z_hsv.cpp:157:14: note: Assignment 'seed=123456789', assigned value is 123456789 glhack-1.2/tools/edtile/z_hsv.cpp:168:30: note: Assignment 'seed=seed*1103515245+12345', assigned value is 136236448760260650 glhack-1.2/tools/edtile/z_hsv.cpp:162:20: note: Integer overflow Explanation: `seed` is an `int`. The expression `seed >> 4` is a right shift, and a right shift can never cause signed integer overflow. The new warning comes from an impossible value: `seed` is given 136236448760260650, a value an `int` cannot hold. That value should have been truncated or dropped when assigned at line 168. The real overflow is the multiplication at line 168, not the shift at line 162. So this warning is a new false positive, caused by the PR's changed value truncation on assignment. ---- 14 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/glvis/glvis_4.5.orig.tar.gz Result: main glvis-4.5/lib/gl/types.hpp:198:36: error: Undefined behaviour: float (256) to integer conversion overflow. [floatConversionOverflow] glvis-4.5/lib/vsdata.cpp:1070:67: note: Calling function 'ColorU8', 4th argument '1.0' value is 1.0 glvis-4.5/lib/gl/types.hpp:198:36: note: float to integer conversion Explanation: With a=1.0, the condition `a >= 1.0` is true, so the code takes the `(uint8_t)255` branch. The `(uint8_t)(a * 256.)` branch is never evaluated for that value. The old warning claimed a 256-to-uint8_t conversion overflow in the unreachable false branch, so it was a false positive. The PR adds floating-point range tracking for `>=`/`<=` conditions and checks for impossible values in the float-to-integer overflow check, which removes this warning. ---- 15 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gnome-keyring/gnome-keyring_51.1.orig.tar.xz Result: your gnome-keyring-51.1/pkcs11/gkm/gkm-sexp.c:264:29: style: Condition 'at' is always true [knownConditionTrueFalse] gnome-keyring-51.1/pkcs11/gkm/gkm-sexp.c:263:6: note: Assuming that condition 'at' is not redundant gnome-keyring-51.1/pkcs11/gkm/gkm-sexp.c:264:29: note: Condition 'at' is always true Explanation: On line 264 the ternary `at ? at : sexp` sits inside `if (at)` from line 263, so the condition `at` really is always true there. The warning is a true positive both before and after the PR. The only difference is that the new output adds notes pointing to the guarding condition on line 263. That makes the report easier to understand. This is a minor message improvement, close to neutral. ---- 16 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/gnucobol3/gnucobol3_3.2.orig.tar.xz Result: main gnucobol-3.2/libcob/termio.c:956:8: style: Condition 'f->data' is always true [knownConditionTrueFalse] Explanation: At line 952 the code returns if f->data == NULL, so f->data is non-null at line 956 and the warning is a true positive. The removed 'main' line is matched by a 'your' line with the same text at the same location. The only difference is that the new output carries extra notes giving the reasoning path ('Assuming that condition f->data==NULL is not redundant'). The warning is effectively unchanged and only gained a supporting error path, so it does not matter to users. ---- 17 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gsad/gsad_27.2.0.orig.tar.gz Result: your greenbone-gsad-24805d1/src/gsad_gmp.c:4354:25: style: Condition 'privacy_host_identifier' is always true [knownConditionTrueFalse] greenbone-gsad-24805d1/src/gsad_gmp.c:4334:15: note: Assuming that condition 'privacy_host_identifier' is not redundant greenbone-gsad-24805d1/src/gsad_gmp.c:4354:25: note: Condition 'privacy_host_identifier' is always true Explanation: Both main and the PR report the same 'privacy_host_identifier is always true' warning at 4354:25, so only the attached notes may differ. The warning is correct. Line 4354 is inside the branch guarded by `if (privacy_host_identifier && !str_equal(...))` at 4334, so `privacy_host_identifier ?: ""` always takes the true side. The PR's note points to that guarding condition, which is accurate. Nothing changes for users. ---- 18 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/k/kdegraphics-thumbnailers/kdegraphics-thumbnailers_26.04.0.orig.tar.xz Result: main kdegraphics-thumbnailers-26.04.0/ps/dscparse.cpp:1048:11: style: Condition 'bytesorlines' is always true [knownConditionTrueFalse] Explanation: Both versions report the same correct warning at line 1048. `bytesorlines` is set to "Bytes" when it is NULL, and the else branch of the `bytesorlines == NULL` check also rules out NULL, so `bytesorlines` is always true there. The diff line differs only in the error-path notes attached to the warning. Main's notes are not shown, so there is no evidence the message got better or worse. The true positive is kept either way. ---- 19 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/k/kissat/kissat_4.0.4.orig.tar.gz Result: your kissat-rel-4.0.4/src/sort.c:22:19: style: Condition 'u' is always true [knownConditionTrueFalse] kissat-rel-4.0.4/src/sort.c:15:7: note: Assuming that condition '!u' is not redundant kissat-rel-4.0.4/src/sort.c:22:19: note: Condition 'u' is always true Explanation: Line 15 returns when `!u`, so `u` is always non-zero at line 22 and the ternary `u ? ... : UINT_MAX` always takes its true branch. Both main and the PR report this true positive. The PR version adds an error path that points to the `!u` check on line 15, which tells the user why the condition is always true. Same warning, clearer message. ---- 20 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/l/lam/lam_7.1.4.orig.tar.gz Result: main lam-7.1.4/share/memory/ptmalloc2/arena.c:520:5: error: Pointer addition with NULL pointer. [nullPointerArithmetic] lam-7.1.4/share/memory/ptmalloc2/arena.c:515:16: note: Assuming allocation function fails lam-7.1.4/share/memory/ptmalloc2/arena.c:515:16: note: Assuming condition 'dev_zero_fd<0' is true lam-7.1.4/share/memory/ptmalloc2/arena.c:515:8: note: Assignment 'p1=(char*)((dev_zero_fd<0)?(dev_zero_fd=open("/dev/zero",O_RDWR),mmap(0,(1024*1024)<<1,PROT_NONE,MAP_PRIVATE|0,dev_zero_fd,0)):mmap(0,(1024*1024)<<1,PROT_NONE,MAP_PRIVATE|0,dev_zero_fd,0))', assigned value is 0 lam-7.1.4/share/memory/ptmalloc2/arena.c:517:10: note: Assignment 'p2=(char*)(((unsigned long)p1+((1024*1024)-1))&~((1024*1024)-1))', assigned value is 0 lam-7.1.4/share/memory/ptmalloc2/arena.c:520:5: note: Null pointer addition Explanation: The removed warning assumes `mmap` failed and returned NULL, so `p1` is 0, `p2` is computed as 0, and `p2 + HEAP_MAX_SIZE` is flagged. But `mmap` signals failure with `MAP_FAILED` ((void*)-1), not NULL, and the code already checks `p1 != MAP_FAILED`. With address hint 0 and no `MAP_FIXED`, a successful `mmap` does not return NULL in practice. So the path where `p1`/`p2` are NULL inside the success branch is infeasible, and the warning was a false positive. The PR's stricter value propagation through the integer cast and mask no longer carries the 0 to `p2`, which removes the false positive. ---- 21 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/l/looking-glass/looking-glass_0+b7+ds1.orig.tar.xz Result: main looking-glass-B7/repos/cimgui/imgui/imgui_tables.cpp:934:37: style: Condition 'column->Flags&ImGuiTableColumnFlags_WidthFixed' is always true [knownConditionTrueFalse] Explanation: The removed main line is replaced by an identical 'your' warning at the same location (config.c:934) with the same text. Only the attached error-path notes differ. The warning is a true positive: line 934 is inside `if (column->Flags & ImGuiTableColumnFlags_WidthFixed)` from line 923, and the flags are not changed in between, so re-testing the same flag is redundant. The diagnostic is kept, so removing the main line does not matter to users. ---- 22 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libb/libbpp-raa/libbpp-raa_2.4.1.orig.tar.gz Result: your bpp-raa-2.4.1/src/Bpp/Raa/RAA_acnuc.c:198:26: style: Condition 'raa_current_db!=NULL' is always true [knownConditionTrueFalse] bpp-raa-2.4.1/src/Bpp/Raa/RAA_acnuc.c:183:22: note: Assuming that condition 'raa_current_db==NULL' is not redundant bpp-raa-2.4.1/src/Bpp/Raa/RAA_acnuc.c:192:17: note: Assuming condition is true bpp-raa-2.4.1/src/Bpp/Raa/RAA_acnuc.c:194:9: note: Assuming condition is true bpp-raa-2.4.1/src/Bpp/Raa/RAA_acnuc.c:198:26: note: Condition 'raa_current_db!=NULL' is always true Explanation: The warning is a true positive in both versions. At line 183 the function returns if `raa_current_db == NULL`, and the pointer is dereferenced at lines 185–197, so `raa_current_db != NULL` at line 198 is always true. The PR keeps the same warning at the same location; only the error-path notes changed. It now adds 'Assuming condition is true' notes for lines 192 and 194. These are superfluous, since non-nullness does not depend on them, but they are not wrong because line 198 is inside both branches. The difference has no practical effect for users. ---- 23 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libn/libnfs/libnfs_5.0.2.orig.tar.gz Result: main libnfs-libnfs-5.0.2/lib/libnfs-zdr.c:337:13: style: Condition '*arrp==NULL' is always false [knownConditionTrueFalse] Explanation: The warning at line 337 ('*arrp==NULL' is always false, based on zdr_malloc returning non-zero) is reported by both main and the PR with the same text. Only the attached notes or error path differ. Whether the warning is right depends on zdr_malloc's implementation, which this PR does not change. The user-visible result is unchanged. ---- 24 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libp/libpsortb/libpsortb_1.0+dfsg.orig.tar.xz Result: main libpsortb-1.0/modhmm0.92b/hmmsearch.c:185:15: style: Condition 'replfile!=NULL' is always true [knownConditionTrueFalse] Explanation: Main and the PR report the same warning at hmmsearch.c:185 with identical text. The only difference is probably in the attached note/error-path lines, which are not shown for main. Whether the warning is right or wrong, the PR neither adds nor removes it, and nothing shows the message became more or less accurate. For users this is effectively unchanged. ---- 25 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libv/libvisual-plugins/libvisual-plugins_0.4.2+dfsg.orig.tar.gz Result: your libvisual-plugins-0.4.2/plugins/actor/JESS/renderer.c:274:11: style: Condition 'aux2>255' is always false [knownConditionTrueFalse] libvisual-plugins-0.4.2/plugins/actor/JESS/renderer.c:272:10: note: Assignment 'aux2=(uint8_t)((float)j*0.245*aux)', assigned value is less than 256 libvisual-plugins-0.4.2/plugins/actor/JESS/renderer.c:274:11: note: Condition 'aux2>255' is always false Explanation: The PR adds this warning. On line 272, `aux2` is assigned `(uint8_t)(...)`, so its value is always in 0..255. The PR's new cast-range impossible values make Cppcheck know this. So `aux2>255` on line 274 really is always false, and the clamp is dead code. The new warning is a true positive, and the note 'assigned value is less than 256' is accurate. ---- 26 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mysql++/mysql++_3.3.0.orig.tar.gz Result: main mysql++-3.3.0/lib/type_info.cpp:297:7: style: Condition 'ti==typeid(sql_varcharsql_varcharsql_varchar)' is always false [knownConditionTrueFalse] Explanation: The same knownConditionTrueFalse warning at type_info.cpp:297 is still reported by the PR with identical text. Only the attached note/error-path lines differ between the two runs. sql_varchar and sql_char are typedefs of std::string, so the condition is redundant after the earlier checks either way. The diagnostic users see is unchanged in substance. ---- 27 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/oas/oas_0.0.20220224.orig.tar.xz Result: your oas/src/oas.c:300:16: style: Condition 'addr!=NULL' is always true [knownConditionTrueFalse] oas/src/oas.c:291:11: note: Assuming that condition 'addr!=NULL' is not redundant oas/src/oas.c:300:16: note: Condition 'addr!=NULL' is always true Explanation: The warning is a true positive in both versions. Line 300 sits inside `if (addr != NULL)` from line 291, and `addr` is never changed in between, so the inner `addr != NULL` check is always true. The only difference is that the new output adds notes pointing to the condition at line 291. That makes the message more informative and easier to verify. ---- 28 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/openvas-scanner/openvas-scanner_23.51.0+ds.orig.tar.xz Result: your greenbone-openvas-scanner-9215eab/nasl/nasl_text_utils.c:209:31: style: int result is assigned to long variable. If the variable is long to avoid loss of information, then you have loss of information. [truncLongCastAssignment] Explanation: Line 209 computes `x = (10 + tolower(s[i+2]) - 'a') * 16`. The guard `isxdigit(s[i+2])` limits the operand to a hex digit, so the int product is at most a few hundred and nothing is lost when it is assigned to the long `x`. The new truncLongCastAssignment warning therefore reports information loss that cannot happen. Line 207 has the same pattern (`(s[i+2]-'0')*16`) and is still not reported. That suggests the PR's changes to integral type deduction (`getCommonIntegralType`) newly typed this expression as plain int and triggered the heuristic. This is a new, noisy false positive rather than a real finding. ---- 29 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/orocos-bfl/orocos-bfl_0.8.0.orig.tar.bz2 Result: main orocos-bfl-0.8.0/tests/smoother_test.cpp:199:54: style: Condition 'time_step+1>0' is always true [knownConditionTrueFalse] Explanation: `time_step` is `unsigned int`. When it is decremented from 0 it wraps to UINT_MAX, so `time_step+1` wraps to 0 and `time_step+1 > 0` becomes false. That wrap is exactly how this loop terminates, so the condition is not always true. Main's knownConditionTrueFalse was a false positive caused by ignoring unsigned wraparound. The PR now skips range bounds on unsigned arithmetic that may wrap, which removes it. ---- 30 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pan/pan_0.165.orig.tar.gz Result: your pan-0.165/uulib/uucheck.c:353:30: style: Condition 'iter!=ptonum' is always true [knownConditionTrueFalse] pan-0.165/uulib/uucheck.c:330:29: note: Assuming that condition 'iter==ptonum' is not redundant pan-0.165/uulib/uucheck.c:336:23: note: Assuming condition is false pan-0.165/uulib/uucheck.c:346:28: note: Assuming condition is false pan-0.165/uulib/uucheck.c:353:30: note: Condition 'iter!=ptonum' is always true Explanation: Both versions report the same warning at the same location; only the attached note path differs. The warning is a true positive. At line 330, the loop does `continue` when `iter == ptonum`, and `iter` is not changed between line 330 and line 353. So `iter != ptonum` at line 353 is always true. The new notes (330, 336, 346) describe a correct path. Main's notes are not shown, so there is no evidence the message got more or less accurate. The same kind of change appears for every warning in this package, so it looks like a cosmetic change to the error path. ---- 31 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/papi/papi_7.2.0.orig.tar.gz Result: your papi-papi-7-2-0-t/src/components/rocm/tests/hl_intercept_multi_thread_monitoring.cpp:93:15: error: Array 'event_list[512]' accessed at index 4294967295, which is out of bounds. [arrayIndexOutOfBounds] papi-papi-7-2-0-t/src/components/rocm/tests/hl_intercept_multi_thread_monitoring.cpp:82:23: note: Assignment 'off=0', assigned value is 0 papi-papi-7-2-0-t/src/components/rocm/tests/hl_intercept_multi_thread_monitoring.cpp:83:19: note: Assuming condition is false papi-papi-7-2-0-t/src/components/rocm/tests/hl_intercept_multi_thread_monitoring.cpp:93:15: note: Array index out of bounds Explanation: `off` is an unsigned starting at 0 and only grows inside the `for (i = 0; i < dev_count; ++i)` loop. If `dev_count` is 0, the loop body never runs and `off` stays 0. Then `event_list[off - 1]` wraps to index 4294967295, which is a real out-of-bounds write. Nothing in the code rules out `dev_count == 0`: the code only checks `hip_errno`, not the device count. The new warning is therefore a plausible true positive. The PR now keeps the loop-not-entered path and models the unsigned wraparound correctly, and its own new test covers this exact pattern. Confidence is medium because the bug depends on HIP reporting success with zero devices. ---- 32 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pidgin/pidgin_2.14.14.orig.tar.bz2 Result: your pidgin-2.14.14/libpurple/protocols/novell/novell.c:263:7: style: Condition 'msg' is always true [knownConditionTrueFalse] pidgin-2.14.14/libpurple/protocols/novell/novell.c:212:26: note: Assuming that condition 'msg==NULL' is not redundant pidgin-2.14.14/libpurple/protocols/novell/novell.c:263:7: note: Condition 'msg' is always true Explanation: Main and the PR both report the same warning at novell.c:263. The early return at line 212 (`msg == NULL`) means `msg` is non-NULL at line 263, so 'Condition msg is always true' is a true positive in both versions. The pair is a re-emission with possibly different notes or error path, not a gained or lost finding, so it makes no practical difference to users. ---- 33 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/poco/poco_1.14.2.orig.tar.bz2 Result: your poco-1.14.2-all/NetSSL_OpenSSL/src/SecureSocketImpl.cpp:601:13: style: Condition 'lastError' is always true [knownConditionTrueFalse] poco-1.14.2-all/NetSSL_OpenSSL/src/SecureSocketImpl.cpp:581:18: note: Assuming that condition 'lastError==0' is not redundant poco-1.14.2-all/NetSSL_OpenSSL/src/SecureSocketImpl.cpp:601:13: note: Condition 'lastError' is always true Explanation: Both main and the PR report the same warning at line 601. It is a true positive: in the else branch of `if (lastError == 0)`, `lastError` is nonzero, so `else if (lastError)` is always true. The diff only shows a change in the attached notes/error path. The PR's path points at the `lastError==0` check on line 581, which is a correct explanation. Main's notes are not shown, so there is no clear gain or loss for users. ---- 34 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/povray/povray_3.8.0~beta.2.orig.tar.gz Result: main povray-3.8.0-beta.2/source/base/image/image.cpp:3110:24: style: Condition 'pb!=nullptr' is always true [knownConditionTrueFalse] Explanation: The same warning is reported by both versions at the same location. The 'your' line has notes attached ('Assignment ... assigned value is never 0'), so the 'main' line only differs in its error path or formatting. Taking the address of a reference result is non-null in valid C++, so the warning is technically correct either way. The developer's comment shows the check is a deliberate defensive workaround. Nothing really changes for users. ---- 35 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/r/reprepro/reprepro_5.5.1.orig.tar.xz Result: main reprepro-5.5.1/log.c:1056:22: style: Condition 'logger->logfile!=NULL' is always true [knownConditionTrueFalse] Explanation: The same warning appears in both outputs at the same location with the same text. Only the attached notes differ between the 'main' and 'your' runs. After the early return at line 1053 when logger->logfile == NULL, the check 'logger->logfile != NULL' at line 1056 is indeed always true. The warning is a true positive in both versions, so the PR does not change what users see in any meaningful way. ---- 36 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/rockdodger/rockdodger_1.1.4.orig.tar.gz Result: main rockdodger-1.1.4/main.c:1078:7: warning: %hX in format string (no. 1) requires 'unsigned short' but the argument type is 'signed int'. [invalidPrintfArgType_uint] Explanation: The argument is `screenshot_number++`. The old code typed the result of `++` as promoted `signed int`, but in C a postfix increment has the type of its operand. The PR now gives inc/dec results the operand's own type. The warning disappeared after that change, so `screenshot_number` is not plain `int`; given the `%02hX` format, it is very likely `unsigned short` (its declaration is not shown). For an `unsigned short` argument, `%hX` is the correct specifier, so the removed invalidPrintfArgType_uint warning was a false positive caused by wrong type deduction. ---- 37 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/roct-thunk-interface/roct-thunk-interface_6.2.4+ds.orig.tar.xz Result: your ROCm-ROCT-Thunk-Interface-5180f47/src/fmm.c:3932:12: style: Condition 'object->registered_device_id_array' is always true [knownConditionTrueFalse] ROCm-ROCT-Thunk-Interface-5180f47/src/fmm.c:3926:6: note: Assuming that condition '!object->registered_device_id_array' is not redundant ROCm-ROCT-Thunk-Interface-5180f47/src/fmm.c:3932:12: note: Condition 'object->registered_device_id_array' is always true Explanation: The same warning, with the same text, is reported by both versions. The only difference is the attached note lines: 'your' shows a note pointing at line 3926, and the main line was likely just missing it in the comparison. The warning itself is correct: line 3926 returns early when registered_device_id_array is NULL, so the check at line 3932 is always true. Users see no meaningful change. ---- 38 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/t/tea/tea_63.3.1.orig.tar.gz Result: your psemiletov-tea-qt-9599b12/src/zip.c:911:11: style: Condition '!p' is always false [knownConditionTrueFalse] psemiletov-tea-qt-9599b12/src/zip.c:908:21: note: Assignment 'p=&((unsigned char*)((&pState->m_central_dir)->m_p))[((unsigned int*)((&pState->m_central_dir_offsets)->m_p))[i]]', assigned value is never 0 psemiletov-tea-qt-9599b12/src/zip.c:911:11: note: Condition '!p' is always false Explanation: Main and the PR report the same warning at the same location with the same text. Only the attached note/error-path details differ, likely because of the PR's error-path and value-property changes. The finding is the same either way: `p` is the address of an array element (`&arr[idx]`), so it cannot be null and `!p` is always false. This is the same true positive in both versions, so the change makes no practical difference to users. ---- 39 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/t/twm/twm_1.0.10.orig.tar.gz Result: main twm-1.0.10/src/menus.c:1157:9: style: Condition 't' is always true [knownConditionTrueFalse] Explanation: The listed source is offset; the warning really belongs to `belongs_to_twm_window`. There, `if (!t) return False;` makes the later `if (t && t->titlebuttons)` check of `t` always true. Both main and the PR report this same correct knownConditionTrueFalse warning; only the attached note/error path differs. The PR's path is still valid, though it adds an irrelevant step ('Assuming condition is false' on the `w == ...` check). Main's original notes are not shown, so the change is essentially cosmetic and does not matter to users. ---- 40 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/u/ucimf-openvanilla/ucimf-openvanilla_2.10.11.orig.tar.gz Result: main ucimf-openvanilla-2.10.11/src/openvanilla.cpp:222:75: error: Signed integer overflow for expression '0x10000-(0xd800<<10)-0xdc00'. [integerOverflow] Explanation: The expression uses only int constants. 0xd800<<10 = 0x3600000 (56623104), which fits in a 32-bit int. 0x10000 - 56623104 - 0xdc00 = -56613888, which is also well inside the int range. No signed overflow happens, so main's integerOverflow error was a false positive. The PR reworks integer type and value computation, and removing this warning is correct. ---- 41 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/u/ucpp/ucpp_1.3.2.orig.tar.gz Result: your macro.c:730:43: warning: If memory allocation fails, then there is a possible null pointer dereference: atl [nullPointerOutOfMemory] macro.c:1147:16: note: Assuming allocation function fails macro.c:1147:16: note: Assignment 'atl=malloc((m->narg+m->vaarg)*sizeof(struct token_fifo))', assigned value is 0 macro.c:1146:19: note: Assuming condition is true macro.c:1149:46: note: Calling function 'collect_arguments', 4th argument 'atl' value is 0 macro.c:730:43: note: Null pointer dereference Explanation: In `macro.c`, `atl` comes from `malloc((m->narg+m->vaarg)*sizeof(struct token_fifo))` at line 1147, and the result is not checked. It is then passed to `collect_arguments()`, where line 730 writes `atl[i].art = atl[i].nt = 0` for each `i < narg`. If the allocation fails and `narg > 0`, this dereferences NULL, so the new nullPointerOutOfMemory warning describes a real unchecked-allocation path. The warning at column 43 (`atl[i].nt`) duplicates the one at column 30 on the same statement, but it is still technically correct. This is a true positive the PR now finds, likely because the new for-loop value handling no longer drops the case where the loop body runs. ---- 42 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/u/ultrastardx/ultrastardx_2026.9.0+dfsg.orig.tar.xz Result: your UltraStar-Deluxe-USDX-8b5324f/src/lib/openCV3/ApiWrapper.cpp:188:15: style: Condition '!src2' is always false [knownConditionTrueFalse] UltraStar-Deluxe-USDX-8b5324f/src/lib/openCV3/ApiWrapper.cpp:188:6: note: Assuming that condition '!src2' is not redundant UltraStar-Deluxe-USDX-8b5324f/src/lib/openCV3/ApiWrapper.cpp:188:15: note: Condition '!src2' is always false Explanation: Line 188 tests `!src2 || !src2 || !dst`. Once the first `!src2` is false, the second one is also false, so the warning is a true positive. It points to a real bug: the code was meant to check `src1`. Both main and your report the same warning text at the same location. The only difference is that your version adds notes: 'Assuming that condition '!src2' is not redundant' at column 6 and 'Condition is always false' at column 15. These notes are accurate and show the user where the duplicate check comes from, so the message is more informative. This is a slight improvement, not a change in detection. ---- 43 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/u/unbound/unbound_1.26.2.orig.tar.gz Result: main unbound-1.26.2/iterator/iterator.c:1904:34: style: Condition 'iq->response' is always true [knownConditionTrueFalse] Explanation: The same warning, 'iq->response' always true at line 1904, is reported by both main and your. The 'main' line has no notes and the 'your' line has notes, so only the error path changed. The warning is correct: iq->response is assigned iq->deleg_msg, which was just checked to be non-null. The message text is identical, so the change does not matter to users. ---- 44 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/v/vcftools/vcftools_0.1.17.orig.tar.gz Result: main vcftools-0.1.17/src/cpp/entry.cpp:936:23: style: Comparing expression of type 'char' against value 129. Condition is always false. [compareValueOutOfTypeRangeError] Explanation: `end_int1` is a static char initialized with `static_cast(0x81)`. On a signed-char platform its value is -127, not 129, so `test_char == end_int1` compares two chars and can be true. Main wrongly took 129 as end_int1's known value. That value is also questionable for a non-const static. The PR's cast handling truncates the value correctly for plain char and no longer reports this false positive. ---- 45 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/v/vsearch/vsearch_2.30.4.orig.tar.gz Result: your torognes-vsearch-23ccc47/src/fastq.cc:489:53: style: Condition 'line_end!=nullptr' is always true [knownConditionTrueFalse] torognes-vsearch-23ccc47/src/fastq.cc:437:19: note: Assuming that condition 'line_end==nullptr' is not redundant torognes-vsearch-23ccc47/src/fastq.cc:487:7: note: Assuming condition is true torognes-vsearch-23ccc47/src/fastq.cc:489:53: note: Condition 'line_end!=nullptr' is always true Explanation: Both main and the PR report the same knownConditionTrueFalse warning for `line_end != nullptr` at line 489. Only the attached note lines differ. The PR's error path cites the loop condition `line_end==nullptr` at line 437 and the `if (plusline_invalid)` at line 487. The second note has nothing to do with `line_end`, so it adds a little noise. The warning text, location and conclusion are unchanged, and main's notes are not shown, so the change hardly matters to users. ---- 46 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/x/xabacus/xabacus_8.5.1.orig.tar.bz2 Result: main xabacus-8.5.1/Abacus.c:3166:17: style: Condition 'pRails-4>0' is always false [knownConditionTrueFalse] xabacus-8.5.1/Abacus.c:3163:17: note: Assuming that condition 'pRails-3>0' is not redundant xabacus-8.5.1/Abacus.c:3166:17: note: Condition 'pRails-4>0' is always false Explanation: pRails is an int computed from widget fields at runtime and is unknown. The code checks it in a chain: `pRails - 3 > 0`, `pRails - 4 > 0`, and so on. If the first condition is true, the second can be true or false, for example when pRails is 4 versus 5. So 'pRails-4>0 is always false' is a false positive. Main wrongly took the 'not redundant' assumption about the earlier condition as an upper bound on later conditions. The PR fixes how possible and impossible range bounds are combined and propagated (infer path handling, isAdjacent, impossible range shifting), and that removes this false positive. ---- 47 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xastir/xastir_2.2.4.orig.tar.gz Result: main Xastir-Release-2.2.4/src/maps.c:9277:11: style: Condition 'iterator' is always true [knownConditionTrueFalse] Explanation: Both versions report the same warning at maps.c:9277. Inside `while (iterator != NULL && temp)`, `iterator` is not modified before the `if (iterator)` check, so the check is redundant and the warning is a true positive. Only the error-path notes differ. The new notes ('Assuming that condition iterator!=NULL is not redundant', 'Assuming condition is true') are slightly odd, since the loop condition already guarantees a non-null value. They neither add nor remove a finding, so the change does not matter to users. ---- 48 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/x/xemacs21-packages/xemacs21-packages_2009.02.17.dfsg.3.orig.tar.gz Result: main xemacs21-packages-2009.02.17.dfsg.3/xemacs-packages/liece/dcc/dcc.c:441:11: style: Condition 'addr!=-1' is always true [knownConditionTrueFalse] Explanation: `addr` is `u_long`, and `addr != -1` is a normal C idiom: `-1` is converted to `ULONG_MAX`, which `primary_address_of()` can return as an error sentinel. The condition is therefore not always true. Main apparently compared an unsigned value that is never negative against a literal -1 without applying the usual arithmetic conversion. The PR models these implicit integral conversions (`getCommonIntegralType`, `truncateImplicitConversion`), so the false positive disappears. ---- 49 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xilinx-bootgen/xilinx-bootgen_2024.2.orig.tar.gz Result: your xilinx-bootgen-2024.2/cJSON.c:390:13: style: Condition 'newbuffer' is always true [knownConditionTrueFalse] xilinx-bootgen-2024.2/cJSON.c:382:13: note: Assuming that condition '!newbuffer' is not redundant xilinx-bootgen-2024.2/cJSON.c:390:13: note: Condition 'newbuffer' is always true Explanation: The same warning, 'newbuffer' is always true at line 390, is reported by both main and your. The code returns early when !newbuffer at line 382, so the check at 390 really is redundant and the warning is a true positive. The only difference is that the PR version adds a note pointing at line 382, which is the reason the condition is always true. The diff lines here likely differ only in that error-path note, not in the finding itself, so this has little effect on users. If anything the note makes the message slightly more informative. ---- 50 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/z/zbar/zbar_0.23.95.orig.tar.gz Result: your zbar-0.23.95/python/zbarmodule.c:266:25: style: Condition 'st->zbar_exc[0]==NULL' is always false [knownConditionTrueFalse] zbar-0.23.95/python/zbarmodule.c:264:23: note: Assignment 'st->zbar_exc[0]=(PyObject*)&zbarException_Type', assigned value is never 0 zbar-0.23.95/python/zbarmodule.c:266:25: note: Condition 'st->zbar_exc[0]==NULL' is always false Explanation: The same knownConditionTrueFalse warning, with identical text at line 266, is reported by both main and the PR. Only the attached notes may differ slightly. The warning is the same before and after: when PY_MAJOR_VERSION < 3 is assumed, st->zbar_exc[0] is assigned the address of a static object, so the NULL check is always false in that configuration. There is no meaningful change for users.