AI review of 2026-10-11_16-26-44-0f05eab65954-results.txt PR: #8899 https://github.com/cppcheck-opensource/cppcheck/pull/8899 Tested: 0f05eab65954d9c6b9c79413429e2767295436d8 Merge base: eb4b6526b3502ee779a74019f814d45d890427ba Reviewed: 2026-10-12 06:49:46 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 137 in the report (random sample), 17 not reviewed: valueFlowMaxIterations Verdicts: 33 improvement, 3 neutral, 14 regression Tokens: 109861 input, 2150600 cache read, 537650 cache write, 32085 output The verdicts are written by AI and can be wrong. ---- 1 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/cmtk/cmtk_3.3.1p2+dfsg.orig.tar.xz Result: main cmtk-3.3.1p2/libs/Numerics/ap.cxx:447:11: warning: Possible null pointer dereference: (void**)(result-sizeof(void*)) [nullPointer] cmtk-3.3.1p2/libs/Numerics/ap.cxx:441:29: note: Assuming allocation function fails cmtk-3.3.1p2/libs/Numerics/ap.cxx:441:29: note: Assignment 'block=malloc(alignment-1+sizeof(void*)+size)', assigned value is 0 cmtk-3.3.1p2/libs/Numerics/ap.cxx:442:36: note: Assignment 'result=(char*)block+sizeof(void*)', assigned value is 8 cmtk-3.3.1p2/libs/Numerics/ap.cxx:447:11: note: Null pointer dereference Explanation: The removed warning is a true positive. At line 441 `block = malloc(...)` is never checked for NULL. If malloc fails, `result` is (char*)0 + sizeof(void*) = 8. When `alignment` divides 8 (e.g. 2, 4 or 8), the `if` at line 445 does not move `result`, so `result - sizeof(void*)` is a null pointer and line 447 writes through it. For other alignments it still writes to a near-null address. The PR's new range/constraint handling in the program memory apparently stops the analysis from reaching this path, so a real unchecked-allocation null dereference is no longer reported. ---- 2 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/condor/condor_25.13.2+dfsg.orig.tar.xz Result: main htcondor-25.13.2/src/condor_utils/classad_merge.cpp:59:9: style: Condition 'equiv' is always false [knownConditionTrueFalse] htcondor-25.13.2/src/condor_utils/classad_merge.cpp:47:16: note: Assignment 'equiv=false', assigned value is 0 htcondor-25.13.2/src/condor_utils/classad_merge.cpp:59:9: note: Condition 'equiv' is always false Explanation: The removed warning was a false positive. `equiv` starts as false, but line 53 sets it to true when both `sPrintExpr` calls return non-NULL and the strings compare equal. So `if (equiv)` at line 59 is not always false. Main apparently mis-evaluated the assignments-in-condition (`from_expr=sPrintExpr(...)` with an unknown right hand side), treating the inner branch as unreachable. The PR changes how unknown right hand sides of assignments are handled in program memory (see the new tests around `(ctx = g) == 0`), which fixes this. Removing the warning is correct. ---- 3 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/c/ctffind/ctffind_4.1.14.orig.tar.gz Result: main ctffind-4.1.14/src/programs/ctffind/ctffind.cpp:2225:53: error: Array 'half_window_width[2147483648]' accessed at index -1, which is out of bounds. [negativeIndex] ctffind-4.1.14/src/programs/ctffind/ctffind.cpp:2208:29: note: Assignment 'bin_of_previous_extremum=0', assigned value is 0 ctffind-4.1.14/src/programs/ctffind/ctffind.cpp:2209:34: note: Assuming condition is false ctffind-4.1.14/src/programs/ctffind/ctffind.cpp:2225:53: note: Negative array index Explanation: Cppcheck reached this warning by assuming the first loop condition `bin_counter(=1) < number_of_bins` is false at entry, i.e. `number_of_bins <= 1`. Then `bin_of_previous_extremum` stays 0. If `number_of_bins` is exactly 1, the second loop runs once and reads `half_window_width[-1]`, so on that path the warning is a real (if unlikely) defect. Main probably got there by treating the false condition as the value 1. The PR records it as the range `<= 1`, so `0 < number_of_bins` is no longer known to be true, and the analysis loses a path that really exists. The code has no guard against this, and the same `-1` index also happens when the extrema profile never changes. So the removal looks like lost precision rather than a removed false positive. The odd array size in the message (2147483648) and the unlikely input make this low confidence. ---- 4 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/d/digikam/digikam_9.1.0.orig.tar.xz Result: main digikam-9.1.0/core/libs/dngwriter/extra/xmp_sdk/source/SafeStringAPIs.cpp:100:14: style: Condition 'n==0' is always false [knownConditionTrueFalse] digikam-9.1.0/core/libs/dngwriter/extra/xmp_sdk/source/SafeStringAPIs.cpp:90:14: note: Assuming that condition 'n==0' is not redundant digikam-9.1.0/core/libs/dngwriter/extra/xmp_sdk/source/SafeStringAPIs.cpp:100:14: note: Condition 'n==0' is always false Explanation: After the check at line 90, n is known to be nonzero. The loop at line 97 then decrements n with '--n > 0', which can bring n down to 0. So the check 'n == 0' at line 100 can be true, and main's 'always false' warning was a false positive. The PR stops treating the earlier 'n != 0' as a fixed value that survives the decrement in the loop condition, so the false positive is removed. ---- 5 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/e/exodusii/exodusii_6.02.dfsg.1.orig.tar.gz Result: main exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:850:5: warning: If memory allocation fails, then there is a possible null pointer dereference: elem_map [nullPointerOutOfMemory] exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:540:25: note: Assuming allocation function fails exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:540:25: note: Assignment 'elem_map=malloc(loc_num_elements*sizeof(INT))', assigned value is 0 exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:538:13: note: Assuming condition is true exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:550:9: note: Calling function 'create_elem_map', 3rd argument 'elem_map' value is 0 exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:850:5: note: Null pointer dereference Explanation: At line 540 `elem_map` is assigned from `malloc(loc_num_elements*sizeof(INT))` and never checked. It is then passed to `create_elem_map()`, which writes `elem_map[i]` for `i < loc_num_elems`. If the allocation fails while `loc_num_elements > 0`, this is a real null dereference, which is exactly what nullPointerOutOfMemory reports. The same unchecked pointer reaches `extract_connect()` (line 876), and that warning also disappears. The removal comes from the PR's reworked program-memory/range handling, not from any check in the code that would rule out the null path. The lines around 538 are not shown, so a correct pruning cannot be fully excluded, but most likely a true positive was lost. ---- 6 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/e/exodusii/exodusii_6.02.dfsg.1.orig.tar.gz Result: main exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:876:9: warning: If memory allocation fails, then there is a possible null pointer dereference: elem_map [nullPointerOutOfMemory] exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:540:25: note: Assuming allocation function fails exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:540:25: note: Assignment 'elem_map=malloc(loc_num_elements*sizeof(INT))', assigned value is 0 exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:538:13: note: Assuming condition is true exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:557:9: note: Calling function 'extract_connect', 3rd argument 'elem_map' value is 0 exodusii-6.02.dfsg.1/exodus/cbind/test/create_mesh.c:876:9: note: Null pointer dereference Explanation: Line 540 assigns `elem_map = malloc(loc_num_elements*sizeof(INT))` and never checks the result. The pointer is then passed to `extract_connect`, which reads `elem_map[j]` at line 876 in a loop over `num_elem` elements. If the allocation fails and there is at least one element, this dereferences NULL. That is exactly what `nullPointerOutOfMemory` is meant to report, so the warning was a true positive. The sibling warning at line 850 (`create_elem_map`) disappeared as well. The code gives no reason why the loop could not run or why the pointer would be non-null. The PR's reworked program-memory and range handling most likely now stops the forwarded null value before the dereference. That makes losing both warnings a regression. Lines 538–557 are not shown, so the exact cause is uncertain. ---- 7 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/f/ftxui/ftxui_6.1.9.orig.tar.gz Result: main FTXUI-6.1.9/src/ftxui/screen/string.cpp:1457:23: style: Condition 'i<-glyph_offset' is always false [knownConditionTrueFalse] Explanation: In the else branch glyph_offset < 0, so -glyph_offset >= 1. The condition 'i < -glyph_offset' is therefore true on the first iteration (i=0). It is not always false. Main likely treated the range 'glyph_offset < 0' as a single point value, so it got a wrong result after negating it. The PR records the condition as a range constraint instead, which removes this false positive. ---- 8 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gftp/gftp_2.9.1~beta.orig.tar.xz Result: your gftp-2.9.1b/lib/config_file.c:387:12: warning: Either the condition 'endpos!=NULL' is redundant or there is possible null pointer dereference: endpos. [nullPointerRedundantCheck] gftp-2.9.1b/lib/config_file.c:359:29: note: Assuming that condition 'endpos!=NULL' is not redundant gftp-2.9.1b/lib/config_file.c:348:47: note: Assuming condition is false gftp-2.9.1b/lib/config_file.c:346:19: note: Assuming condition is true gftp-2.9.1b/lib/config_file.c:387:12: note: Null pointer dereference Explanation: Inside the while loop at line 359, `endpos = strchr(endpos + 1, ':')` can set endpos to NULL, for example when a line ends with an escaped colon and has no further ':'. The `endpos != NULL` check in the loop condition admits this. Nothing after the loop re-checks endpos, so it is dereferenced at 370/371 and again at 387 (`*endpos == '\0'`). The reported path (condition true at 346, strchr succeeds at 348, loop leaves endpos NULL) is feasible, so this is a real potential null dereference. The first dereference is really at line 370, so the location is not ideal, and main may already have reported that line. The new warning is still a correct finding about the same real bug. ---- 9 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/golang-github-bep-gowebp/golang-github-bep-gowebp_0.4.0+dfsg.orig.tar.xz Result: main gowebp-0.4.0/libwebp_src/src/enc/frame_enc.c:698:27: warning: Uninitialized variable: it [uninitvar] gowebp-0.4.0/libwebp_src/src/enc/frame_enc.c:893:27: note: Calling function 'PostLoopFinalize', 1st argument '&it' value is gowebp-0.4.0/libwebp_src/src/enc/frame_enc.c:698:27: note: Uninitialized variable: it Explanation: `PostLoopFinalize(&it, ok)` is called after the pass loop in `VP8EncTokenLoop`, and `it` is set by `VP8IteratorInit` inside that loop. The loop is `while (ok && num_pass_left-- > 0)`. In upstream libwebp it follows `assert(num_pass_left > 0)` and `ok` is known to be 1 there, so the body runs at least once. The surrounding code was not shown, so this relies on the upstream source. Under that reading, `it` is always initialized when `PostLoopFinalize` reads `it->enc_`, and the uninitvar warning was a false positive. The PR records conditions such as `x > 0` as ranges in program memory, so Cppcheck plausibly now sees that the loop cannot be skipped. Removing this warning is an improvement. ---- 10 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/h/hdf5/hdf5_2.2.0+repack.orig.tar.gz Result: your hdf5-2.2.0+repack/test/trefstr.c:264:18: warning:inconclusive: Either the condition '!s' is redundant or there is possible null pointer dereference: s. [nullPointerRedundantCheck] hdf5-2.2.0+repack/test/trefstr.c:260:5: note: Assuming that condition '!s' is not redundant hdf5-2.2.0+repack/test/trefstr.c:260:5: note: Assuming condition is true hdf5-2.2.0+repack/test/trefstr.c:264:18: note: Null pointer dereference Explanation: In HDF5's test framework, CHECK_PTR(s, ...) only prints an error when s is NULL; it does not return or abort. So after the NULL check on line 260, execution continues. When s is NULL, `s == buf` is false because buf is an array, and strcmp(s, buf) on line 264 then dereferences NULL. This is the usual 'redundant check or null dereference' pattern that cppcheck reports. The new ProgramMemory handling appears to let the analysis carry the null value through the intervening `s == buf` condition, which main did not manage. In test code this has little practical impact, but the warning is consistent and correct. ---- 11 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/l/liquid-dsp/liquid-dsp_1.8.3.orig.tar.xz Result: your liquid-dsp-1.8.3/sandbox/svd_test.c:148:16: warning: Uninitialized variable: l [uninitvar] liquid-dsp-1.8.3/sandbox/svd_test.c:74:16: note: Assuming condition is false liquid-dsp-1.8.3/sandbox/svd_test.c:148:16: note: Uninitialized variable: l Explanation: The new warning assumes the loop condition at line 74 (column 16 is likely the `i=0; i--)`, also never runs, so line 148 is unreachable with `l` uninitialized. This looks like a false positive: the PR's new handling of ranges and constraints seems to lose the link between the two loop bounds. The confidence is medium because lines 74–107 are not shown. ---- 12 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/maq/maq_0.7.1.orig.tar.gz Result: main maq-0.7.1/stdaln.c:758:4: warning: If memory allocation fails, then there is a possible null pointer dereference: seq22 [nullPointerOutOfMemory] maq-0.7.1/stdaln.c:746:33: note: Assuming allocation function fails maq-0.7.1/stdaln.c:746:10: note: Assignment 'seq22=(unsigned char*)malloc(sizeof(unsigned char)*len2)', assigned value is 0 maq-0.7.1/stdaln.c:758:4: note: Null pointer dereference Explanation: Both `seq11` and `seq22` come from an unchecked `malloc` and are then written in every branch of the `ap->row` if/else chain, so a failed allocation leads to a null dereference whichever branch runs. Main reported this in the `ap->row < 20` branch (lines 756/758). That choice likely came from the old behaviour of treating `!(ap->row < 10)` as the single value `ap->row == 10`. The PR records a range instead, and the same true positive is now reported in the amino-acid branch (lines 761/763). Users get the same valid warning for the same variables, only at a different but equally correct line, so this is neither a gain nor a loss. ---- 13 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/maq/maq_0.7.1.orig.tar.gz Result: your maq-0.7.1/stdaln.c:761:4: warning: If memory allocation fails, then there is a possible null pointer dereference: seq11 [nullPointerOutOfMemory] maq-0.7.1/stdaln.c:745:33: note: Assuming allocation function fails maq-0.7.1/stdaln.c:745:10: note: Assignment 'seq11=(unsigned char*)malloc(sizeof(unsigned char)*len1)', assigned value is 0 maq-0.7.1/stdaln.c:761:4: note: Null pointer dereference Explanation: `seq11` comes from an unchecked malloc at line 745 and is written in loops in every branch (lines 751, 756 and 761). A failed allocation would cause a null dereference in any of them. Main reported the nt16 branch (line 756); the PR reports the amino-acid branch (line 761) instead. The paired seq22 warning moved the same way (758 to 763). It is the same true positive at a different, equally valid spot, so it makes no practical difference to users. ---- 14 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/mate-calc/mate-calc_1.28.0.orig.tar.xz Result: main mate-calc-1.28.0/src/mp-binary.c:178:27: style: Condition 'i<-count' is always false [knownConditionTrueFalse] Explanation: In the else branch count < 0, so -count > 0, and the loop condition 'i < -count' is true on the first iteration (i = 0). Main wrongly reported it as always false. The old program memory probably took the bound from 'count >= 0' (false branch: count <= -1) as the single value -1. It then advanced i during loop analysis and concluded the condition was false. The PR records conditions with bounds as impossible ranges instead of single values, so this false positive is gone. ---- 15 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mgba/mgba_0.10.5+dfsg.orig.tar.xz Result: your mgba-emu-mgba-26b7884/src/gba/bios.c:360:30: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: Line 360 is reached when y >= 0 and the earlier branches did not return. One such path is x < 0 with -x < y, for example x = -1, y = 5. On that path `x << 14` shifts a negative int32_t, which is technically undefined behaviour. With the new range tracking, Cppcheck now knows x can be negative here, so the new shiftNegativeLHS warning at column 30 (the `<<`) is a true positive. ---- 16 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/micropython/micropython_1.26.1+ds.orig.tar.xz Result: main micropython-1.26.1/lib/libm/log1pf.c:58:6: style: Condition 'k' is always true [knownConditionTrueFalse] micropython-1.26.1/lib/libm/log1pf.c:38:6: note: Assignment 'k=1', assigned value is 1 micropython-1.26.1/lib/libm/log1pf.c:58:6: note: Condition 'k' is always true Explanation: The `k = 0` assignment at line 52 is reachable. Take a positive x with ix = 0x3e000000: it passes `ix < 0x3ed413d0`, fails `ix >= 0xbf800000`, and fails the `ix<<1 < 0x33800000<<1` check, so it reaches `ix <= 0xbe95f619`, which is true. So `if (k)` at line 58 can see k == 0, and 'Condition k is always true' was a false positive. Main probably got this wrong by treating a range from a comparison as a single value; the PR records ranges as constraints instead, which removes the false positive. ---- 17 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/micropython/micropython_1.26.1+ds.orig.tar.xz Result: main micropython-1.26.1/lib/libm_dbl/log1p.c:97:6: style: Condition 'k' is always true [knownConditionTrueFalse] micropython-1.26.1/lib/libm_dbl/log1p.c:77:6: note: Assignment 'k=1', assigned value is 1 micropython-1.26.1/lib/libm_dbl/log1p.c:97:6: note: Condition 'k' is always true Explanation: `k` is set to 1 at line 77, but line 91 sets it to 0 when `hx <= 0xbfd2bec4` inside the first branch. That path is reachable: for x = -0.2, hx = 0xbfc99999, so `hx>>31` is true, `hx < 0xbff00000`, `hx<<1` is not below the threshold, and `hx <= 0xbfd2bec4` holds. So `k` can be 0 at line 97, and 'Condition k is always true' was a false positive. Main probably turned a range condition into a single point value, which the PR fixes by recording ranges as constraints. Removing the warning is correct. ---- 18 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/musescore-snapshot/musescore-snapshot_3.2.s20190704+dfsg1.orig.tar.xz Result: main musescore-snapshot-3.2.s20190704+dfsg1.orig/libmscore/note.cpp:1941:31: style: Condition 'i<-n' is always false [knownConditionTrueFalse] Explanation: Inside 'if (n < 0)', the loop condition 'i < -n' starts as 0 < -n, which is true because -n is positive, and then goes false as i grows. So it is not always false. Main wrongly treated the range 'n < 0' as one concrete value (n == -1, so -n == 1) and then evaluated the condition after i++ as 1 < 1. The PR records ranges as constraints in program memory instead of single values, which removes this false positive. ---- 19 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/musescore-snapshot/musescore-snapshot_3.2.s20190704+dfsg1.orig.tar.xz Result: main musescore-snapshot-3.2.s20190704+dfsg1.orig/mscore/chordview.cpp:354:37: style: Condition 'i<-step' is always false [knownConditionTrueFalse] Explanation: In the else branch step <= 0, so -step >= 0. The loop condition 'i < -step' with i = 0 is false only when step == 0 and true for any negative step. Main wrongly reported it as always false, likely because it treated the condition 'step > 0' as a single value instead of a range. The PR records conditions with bounds as ranges, so this false positive is gone. ---- 20 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/musescore-snapshot/musescore-snapshot_3.2.s20190704+dfsg1.orig.tar.xz Result: main musescore-snapshot-3.2.s20190704+dfsg1.orig/mscore/importgtp.cpp:2528:31: warning: Possible null pointer dereference: lastRest [nullPointer] musescore-snapshot-3.2.s20190704+dfsg1.orig/mscore/importgtp.cpp:2507:36: note: Assignment 'lastRest=nullptr', assigned value is 0 musescore-snapshot-3.2.s20190704+dfsg1.orig/mscore/importgtp.cpp:2508:53: note: Assuming condition is false musescore-snapshot-3.2.s20190704+dfsg1.orig/mscore/importgtp.cpp:2528:31: note: Null pointer dereference Explanation: `lastRest` is set to a non-null `cr` in the same branch that increments `counter`. If the loop never assigns it (for example when the loop body never runs), `counter` stays 0, so the `counter == 1` guard is false. So `lastRest` is never null at line 2528, and main's warning, which assumes the loop condition is false, is a false positive. The PR changes how program memory tracks values, so `counter == 1` is no longer treated as possible on that path. Removing the warning is an improvement. ---- 21 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/musescore-snapshot/musescore-snapshot_3.2.s20190704+dfsg1.orig.tar.xz Result: main musescore-snapshot-3.2.s20190704+dfsg1.orig/mscore/importgtp.cpp:2529:31: warning: Possible null pointer dereference: lastRest [nullPointer] musescore-snapshot-3.2.s20190704+dfsg1.orig/mscore/importgtp.cpp:2507:36: note: Assignment 'lastRest=nullptr', assigned value is 0 musescore-snapshot-3.2.s20190704+dfsg1.orig/mscore/importgtp.cpp:2508:53: note: Assuming condition is false musescore-snapshot-3.2.s20190704+dfsg1.orig/mscore/importgtp.cpp:2529:31: note: Null pointer dereference Explanation: lastRest starts as nullptr and is set inside the loop whenever counter is incremented. Line 2529 runs only when counter == 1, so the loop must have assigned lastRest, and it cannot be null there. Main assumed the loop condition was false on the first iteration, which leaves counter at 0, and that contradicts the counter == 1 check. The PR's handling of constraints in program memory now ties counter to the assignment, so this false positive is gone. ---- 22 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/musescore-snapshot/musescore-snapshot_3.2.s20190704+dfsg1.orig.tar.xz Result: main musescore-snapshot-3.2.s20190704+dfsg1.orig/omr/omrview.cpp:320:31: style: Condition 'i<-step' is always false [knownConditionTrueFalse] Explanation: In the else branch step <= 0, so -step >= 0. When step < 0, 'i < -step' is true on the first iteration (i = 0), so the condition is not always false. Main wrongly treated the range 'step <= 0' as the single value step == 0. The PR records the condition as a range constraint instead of a point value, which removes this false positive. ---- 23 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nginx-confgen/nginx-confgen_2.2.orig.tar.xz Result: your nginx-confgen-2.2/nginx-confgen.c:542:5: warning: If memory allocation fails, then there is a possible null pointer dereference: ret [nullPointerOutOfMemory] nginx-confgen-2.2/nginx-confgen.c:494:29: note: Assuming allocation function fails nginx-confgen-2.2/nginx-confgen.c:494:29: note: Assignment 'ret=malloc(size)', assigned value is 0 nginx-confgen-2.2/nginx-confgen.c:500:11: note: Assuming condition is false nginx-confgen-2.2/nginx-confgen.c:542:5: note: Null pointer dereference Explanation: In proc_subst_vars, line 494 sets `ret = malloc(size)`. The notes show no NULL check before the loop at line 500. If the input string is empty, the loop body never runs and `addc(0)` at line 542 writes `ret[0]` (len is 0 and size is positive, so no realloc happens). If malloc failed, that dereferences NULL, so the new nullPointerOutOfMemory warning looks like a true positive. The PR's program-memory changes stop unknown or recorded values from hiding the null path; its new nullpointer112 test adds a nullPointerOutOfMemory case of the same kind. The addc macro and lines 494-499 are not shown, so confidence is medium. ---- 24 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/n/node-iconv/node-iconv_3.0.1+~3.0.4.orig.tar.gz Result: your bnoordhuis-node-iconv-c6e7dc6/deps/libiconv/lib/cp932.h:114:33: style: Condition 's1<=0xf9' is always true [knownConditionTrueFalse] bnoordhuis-node-iconv-c6e7dc6/deps/libiconv/lib/cp932.h:110:66: note: Assuming that condition 's1>=0xfa' is not redundant bnoordhuis-node-iconv-c6e7dc6/deps/libiconv/lib/cp932.h:114:33: note: Condition 's1<=0xf9' is always true Explanation: Line 114 is only reached when the condition on line 110 is false, so `s1 >= 0xfa` is false and `s1 <= 0xf9` must hold. The `s1<=0xf9` part of the condition is therefore redundant, and the warning is a true positive. The PR now keeps the range `s1 < 0xfa` from the failed condition instead of dropping it, so this new knownConditionTrueFalse finding comes from Cppcheck understanding the code better. ---- 25 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nss-pem/nss-pem_1.1.1+1.orig.tar.xz Result: main nss-pem-1.1.1+1/nss/nss/lib/sqlite/sqlite3.c:150910:12: style: Condition 'j<(int)(sizeof(yy_lookahead)/sizeof(yy_lookahead[0]))' is always false [knownConditionTrueFalse] nss-pem-1.1.1+1/nss/nss/lib/sqlite/sqlite3.c:150884:10: note: Assuming that condition 'i>=((int)(sizeof(yy_lookahead)/sizeof(yy_lookahead[0])))' is not redundant nss-pem-1.1.1+1/nss/nss/lib/sqlite/sqlite3.c:150911:52: note: Assuming that condition 'iLookAhead>0' is not redundant nss-pem-1.1.1+1/nss/nss/lib/sqlite/sqlite3.c:150902:32: note: Assignment 'j=i-iLookAhead+95', assigned value is greater than 2263 nss-pem-1.1.1+1/nss/nss/lib/sqlite/sqlite3.c:150910:12: note: Condition 'j<(int)(sizeof(yy_lookahead)/sizeof(yy_lookahead[0]))' is always false Explanation: This is SQLite's Lemon parser function yy_find_shift_action. The block is entered when `i>=YY_NLOOKAHEAD || yy_lookahead[i]!=iLookAhead`. The asserts keep i below the table size, so the block is normally entered through the lookahead mismatch. There, `j = i - iLookAhead + YYWILDCARD` can be inside the table, so the generated bounds check `j < sizeof(yy_lookahead)/...` is not always false. Main's chain assumes only the `i>=N` operand and then concludes j>2263. This looks like the old program-memory behaviour that the PR fixes: a bound from a condition such as `i>=N` was treated like a concrete value. With ranges kept as constraints, the false positive disappears. ---- 26 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nss-pem/nss-pem_1.1.1+1.orig.tar.xz Result: your nss-pem-1.1.1+1/nss/nss/lib/sqlite/sqlite3.c:23031:4: warning: Either the condition 'pPrior!=0' is redundant or there is overflow in pointer subtraction. [nullPointerArithmeticRedundantCheck] nss-pem-1.1.1+1/nss/nss/lib/sqlite/sqlite3.c:23029:17: note: Assuming that condition 'pPrior!=0' is not redundant nss-pem-1.1.1+1/nss/nss/lib/sqlite/sqlite3.c:23028:22: note: Assignment 'p=(long long*)pPrior', assigned value is 0 nss-pem-1.1.1+1/nss/nss/lib/sqlite/sqlite3.c:23031:4: note: Null pointer subtraction Explanation: The file was not in the package, but the notes point to SQLite's sqlite3MemFree(): `sqlite3_int64 *p = (sqlite3_int64*)pPrior; assert( pPrior!=0 ); p--;`. The column positions in the notes match this shape. The `pPrior!=0` check is an assert placed between the assignment and the decrement. Once execution passes the assert, pPrior, and therefore p (an alias of pPrior), is non-null, so `p--` can never be a null pointer subtraction. Cppcheck should take the assert into account and see that p equals pPrior. The new warning ignores the assert and treats p as possibly null at the decrement. Main did not report this; the PR adds a false positive. ---- 27 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/n/nss/nss_3.130.orig.tar.gz Result: main nss-3.130/nss/lib/sqlite/sqlite3.c:45545:13: style: Condition 'bUnlock' is always true [knownConditionTrueFalse] nss-3.130/nss/lib/sqlite/sqlite3.c:45526:23: note: Assignment 'bUnlock=1', assigned value is 1 nss-3.130/nss/lib/sqlite/sqlite3.c:45545:13: note: Condition 'bUnlock' is always true Explanation: `bUnlock` starts as 1 but is set to 0 at line 45539 when `aLock[ofst]>1`. Only `assert(aLock[ofst]>=1)` precedes that check, so `aLock[ofst]>1` can be true and `bUnlock` is not always true. Main most likely recorded the assert as `aLock[ofst]` having one exact value, which wrongly made the inner `if` dead. That is exactly the bug the PR fixes: a comparison is now stored as a range, not a single value (see the new tests for `x > 3`). The false positive is gone. ---- 28 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nss/nss_3.130.orig.tar.gz Result: your nss-3.130/nss/lib/sqlite/shell.c:7658:11: warning: Shifting signed 64-bit value by 63 bits is undefined behaviour. See condition at line 7655. [shiftTooManyBitsSigned] nss-3.130/nss/lib/sqlite/shell.c:7655:15: note: Assuming that condition '1-e>=64' is not redundant nss-3.130/nss/lib/sqlite/shell.c:7658:11: note: Shift Explanation: The new warning is on `m >>= 1-e` in the else branch of `if (1-e >= 64)`, so the shift amount is at most 63. That is a right shift. m is non-negative here: negative m is negated, and the only value that cannot be negated returns early. Right-shifting a non-negative signed 64-bit value by 63 is well defined and gives 0, so the claim of undefined behaviour is wrong. The 63 value from the condition is reachable (e can be -62 at that point), but the warning about it is a false positive. The PR's range tracking now feeds this value to the shiftTooManyBitsSigned check, which does not tell left shifts from right shifts here. The result is a new false positive. ---- 29 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nss/nss_3.130.orig.tar.gz Result: your nss-3.130/nss/lib/sqlite/sqlite3.c:28077:4: warning: Either the condition 'pPrior!=0' is redundant or there is overflow in pointer subtraction. [nullPointerArithmeticRedundantCheck] nss-3.130/nss/lib/sqlite/sqlite3.c:28075:17: note: Assuming that condition 'pPrior!=0' is not redundant nss-3.130/nss/lib/sqlite/sqlite3.c:28074:22: note: Assignment 'p=(long long*)pPrior', assigned value is 0 nss-3.130/nss/lib/sqlite/sqlite3.c:28077:4: note: Null pointer subtraction Explanation: In sqlite3MemRealloc, `p` is set from `pPrior` and then `assert( pPrior!=0 && nByte>0 )` runs. Only after that does `p--` execute. If `pPrior` were 0, the assert would fail before the subtraction. The comment above the function also states that `pPrior` is never 0 here. The condition is an assertion of the precondition, not a redundant check guarding a real null path. Reporting null pointer subtraction at `p--` is therefore a false positive. It appeared because the reworked program memory no longer applies the assert's constraint on this path. ---- 30 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/onednn/onednn_3.12.1+ds.orig.tar.xz Result: main uxlfoundation-oneDNN-c8c37fd/tests/benchdnn/dnnl_memory.cpp:453:28: error: Shifting by a negative value is undefined behaviour [shiftNegative] Explanation: The loop runs `i` from 0 while `i < ndims`, and `d = ndims - 1 - i`. So `d` goes from `ndims-1` down to 0 and is never negative, which makes `1 << d` well defined. The shiftNegative warning in main was a false positive. It likely came from main treating a range condition as a single point value. The PR records such conditions as ranges instead, so removing this warning is correct. ---- 31 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/orbvis/orbvis_0.3.4.orig.tar.gz Result: main wojciech-graj-OrbVis-5ab27b5/lib/stb_image/stb_image.h:4327:44: warning: Uninitialized variable: lencodes [uninitvar] wojciech-graj-OrbVis-5ab27b5/lib/stb_image/stb_image.h:4303:13: note: Assuming condition is false wojciech-graj-OrbVis-5ab27b5/lib/stb_image/stb_image.h:4327:44: note: Uninitialized variable: lencodes Explanation: The removed warning claims `lencodes` is uninitialized at line 4327 on a path where `while (n < ntot)` is false on its first test. That path cannot reach line 4327. On it `n` is 0, and the check `if (n != ntot) return` only passes if `ntot` is 0. But `ntot = hlit + hdist`, where `hlit >= 257` and `hdist >= 1`, so `ntot` is never 0. On every path that does reach line 4327, the loop has written `lencodes[0..ntot-1]`. The warning was a false positive, so removing it is an improvement, consistent with the PR's more precise handling of conditions. ---- 32 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/phyml/phyml_3.3.20250515.orig.tar.gz Result: your stephaneguindon-phyml-76a39c8/src/utilities.c:14534:13: warning: Uninitialized variable: dv [uninitvar] stephaneguindon-phyml-76a39c8/src/utilities.c:14526:17: note: Assuming condition is false stephaneguindon-phyml-76a39c8/src/utilities.c:14534:13: note: Uninitialized variable: dv Explanation: The loop sets `dv = i` and breaks when `d->v[i] == v`. The following `assert(i != 3)` guarantees the loop exited through the break, so `dv` is always initialized when `d->b[dv]` is read. The identical pattern for `dw` just above is not reported, which shows the new warning comes from the analysis losing the link between `i` and the assert, not from a real bug. This is a new false positive introduced by the PR's program-memory changes. ---- 33 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/picocom/picocom_2024-07.orig.tar.xz Result: main picocom-2024-07/picocom.c:1576:37: error: Uninitialized variable: buff_map [uninitvar] Explanation: In the else branch `n` is known to be > 0, because `n == 0` and `n < 0` are both false. So the loop runs at least once, and `do_map` writes into `buff_map` through `bmp` before `writen_ni` reads it. The old program memory turned the condition `!(n < 0)` into the point value n = 0. It then decided that the loop `i < n` never runs and reported `buff_map` as uninitialized. The PR records `n >= 0` as a range constraint, combined with `n != 0`, so the false positive is gone. ---- 34 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/psicode/psicode_3.4.0.orig.tar.gz Result: main psi3/src/lib/libciomr/eigsort.cc:132:17: style: Condition 'i 1, and the 'always false' warning was a false positive. Main recorded the condition `nmo < 0` as the single value nmo == -1 (the bound value). Then abs gave 1 and the loop condition became `0 < 0`. The PR records `nmo < 0` as a range constraint instead of a point value, so the bogus conclusion goes away. ---- 35 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/psicode/psicode_3.4.0.orig.tar.gz Result: your psi3/src/bin/cclambda/check_sum.cc:65:58: warning: Uninitialized variable: norm [uninitvar] psi3/src/bin/cclambda/check_sum.cc:34:18: note: Assuming condition is false psi3/src/bin/cclambda/check_sum.cc:49:23: note: Assuming condition is false psi3/src/bin/cclambda/check_sum.cc:65:58: note: Uninitialized variable: norm Explanation: `norm` is assigned only when `params.ref <= 1` or `params.ref == 2`. For any other value of `ref`, `norm` is read uninitialized at line 65, so the warning is a true positive. Before the PR, program memory recorded the false branch of `ref <= 1` as the single value `ref == 2`. That made the `else if` look always true, hid the uninit path from the ValueFlow checker, and left only the legacy check to report it. The PR records `ref > 1` as a range, so the ValueFlow checker now finds the path (`ref > 1` and `ref != 2`) and reports it with explanatory notes. The legacy report goes away and is replaced by the same diagnosis with a path explanation. The warning severity also fits better, since the problem occurs only on a conditional path. ---- 36 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/r/racket/racket_8.18+dfsg1.orig.tar.xz Result: main racket-8.18+dfsg1/src/ChezScheme/zlib/examples/enough.c:517:53: style: Condition 'g.max<1' is always false [knownConditionTrueFalse] racket-8.18+dfsg1/src/ChezScheme/zlib/examples/enough.c:508:13: note: Assignment 'g.max=15', assigned value is 15 racket-8.18+dfsg1/src/ChezScheme/zlib/examples/enough.c:517:53: note: Condition 'g.max<1' is always false Explanation: `g.max` is set to 15 only by default. When argc == 4 (argc > 3 and not argc > 4), `g.max = atoi(argv[3])` can be any value, so `g.max < 1` can be true. The removed 'always false' warning was a false positive. The PR stops treating a range from a condition (e.g. `argc > 4` being false) as a single concrete value, which plausibly explains why it is gone. ---- 37 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/racket/racket_8.18+dfsg1.orig.tar.xz Result: main racket-8.18+dfsg1/src/myssink/sink.cxx:289:9: warning: Either the condition 'ii>=128' is redundant or the array 'argv[128]' is accessed at index 128, which is out of bounds. [arrayIndexOutOfBoundsCond] racket-8.18+dfsg1/src/myssink/sink.cxx:281:14: note: Assuming that condition 'ii>=128' is not redundant racket-8.18+dfsg1/src/myssink/sink.cxx:286:7: note: ii is incremented', new value is 128 racket-8.18+dfsg1/src/myssink/sink.cxx:280:14: note: Assuming condition is true racket-8.18+dfsg1/src/myssink/sink.cxx:289:9: note: Array index out of bounds Explanation: The warning is a real edge-case bug. In the inner loop the guard `if (ii >= MAXINVOKEARGS)` passes with ii == 127, then `ii++` makes ii 128. If `namedArgs[j].dispId == 128`, the loop exits without re-checking, so `argv[ii]` at line 289 writes `argv[128]`, one past the end of the 128-element array. The PR's new range handling apparently loses this path and drops the warning. That removes a true positive. ---- 38 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/racket/racket_8.18+dfsg1.orig.tar.xz Result: main racket-8.18+dfsg1/src/myssink/sink.cxx:290:14: warning: Either the condition 'ii>=128' is redundant or the array 'argv[128]' is accessed at index 128, which is out of bounds. [arrayIndexOutOfBoundsCond] racket-8.18+dfsg1/src/myssink/sink.cxx:281:14: note: Assuming that condition 'ii>=128' is not redundant racket-8.18+dfsg1/src/myssink/sink.cxx:286:7: note: ii is incremented', new value is 128 racket-8.18+dfsg1/src/myssink/sink.cxx:280:14: note: Assuming condition is true racket-8.18+dfsg1/src/myssink/sink.cxx:290:14: note: Array index out of bounds Explanation: The inner loop checks `ii >= 128` before writing `argv[ii]` and then increments `ii`. If `namedArgs[j].dispId == 128`, `ii` can go from 127 to 128 and the loop exits because `128 < 128` is false. The check at line 281 is not reached again, and the outer check at line 276 only runs at the start of the next outer iteration. So line 289 writes `argv[128]` and line 290 reads it, both out of bounds. The warning describes a real path and is a true positive. The PR removed it, along with the matching warning at line 289, most likely because of its new range handling in program memory. ---- 39 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/racket/racket_8.18+dfsg1.orig.tar.xz Result: main racket-8.18+dfsg1/src/zuo/zuo.c:4220:13: style: Condition 'amt>4096' is always false [knownConditionTrueFalse] racket-8.18+dfsg1/src/zuo/zuo.c:4210:18: note: Assignment 'sz=256', assigned value is 256 racket-8.18+dfsg1/src/zuo/zuo.c:4213:28: note: Assuming that condition 'sz>amount' is not redundant racket-8.18+dfsg1/src/zuo/zuo.c:4214:10: note: Assignment 'sz=amount', assigned value is 255 racket-8.18+dfsg1/src/zuo/zuo.c:4213:21: note: Assuming condition is true racket-8.18+dfsg1/src/zuo/zuo.c:4210:32: note: Assignment 'offset=0', assigned value is 0 racket-8.18+dfsg1/src/zuo/zuo.c:4219:24: note: Assignment 'amt=sz-offset', assigned value is less than 256 racket-8.18+dfsg1/src/zuo/zuo.c:4220:13: note: Condition 'amt>4096' is always false Explanation: In zuo_drain, `sz` starts at 256 and is only lowered to `amount` when `amount` is smaller. The loop reads into a buffer that presumably grows as `offset` approaches `sz`, so `amt = sz - offset` can exceed 4096 in later iterations. The removed warning rests on the trace 'sz=amount, assigned value is 255'. That comes from treating the condition `sz > amount` as if it made `amount` exactly 255. This is the bug the PR fixes: a range from a condition is now recorded as a constraint, not as a single value. The 'always false' warning was therefore a false positive, and removing it is good. ---- 40 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/scummvm/scummvm_2026.1.0+dfsg.orig.tar.xz Result: main scummvm-2026.1.0/engines/cruise/backgroundIncrust.cpp:317:4: warning: Either the condition '!pNext' is redundant or there is possible null pointer dereference: bx. [nullPointerRedundantCheck] scummvm-2026.1.0/engines/cruise/backgroundIncrust.cpp:313:8: note: Assuming that condition '!pNext' is not redundant scummvm-2026.1.0/engines/cruise/backgroundIncrust.cpp:311:34: note: Assignment 'cx=pNext', assigned value is 0 scummvm-2026.1.0/engines/cruise/backgroundIncrust.cpp:313:8: note: Assuming condition is false scummvm-2026.1.0/engines/cruise/backgroundIncrust.cpp:316:7: note: bx is assigned 'cx' here. scummvm-2026.1.0/engines/cruise/backgroundIncrust.cpp:317:4: note: Null pointer dereference Explanation: At line 317, `bx` is `cx`. `cx` is `pNext` when `pNext` is non-null, and `pHead` when it is null (`if (!pNext) cx = pHead;`). `pHead` cannot be null because `pHead->next` was already dereferenced. So `bx` is never null there. The warning's own trace is contradictory: it says `cx` is 0 (so `pNext` is 0) while assuming `!pNext` is false. The removed warning was a false positive, likely dropped because the PR's program-memory handling now keeps `pNext` and `cx` consistent. ---- 41 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/scummvm/scummvm_2026.1.0+dfsg.orig.tar.xz Result: main scummvm-2026.1.0/engines/sky/debug.cpp:1190:9: style: Condition 'showAll' is always false [knownConditionTrueFalse] scummvm-2026.1.0/engines/sky/debug.cpp:1176:18: note: Assignment 'showAll=false', assigned value is 0 scummvm-2026.1.0/engines/sky/debug.cpp:1188:30: note: Assuming condition is true scummvm-2026.1.0/engines/sky/debug.cpp:1190:9: note: Condition 'showAll' is always false Explanation: `showAll` is set to true when `argc == 4` and `argv[3]` is "all". In that case `sectionNumber` comes from `atoi(argv[2])` and passes the range check, so line 1190 can be reached with `showAll == true`. The old 'always false' warning was a false positive. It most likely came from the old program memory treating a range condition, such as the check on `sectionNumber`, as one exact value. The PR records such conditions as ranges instead, so removing this warning is an improvement. ---- 42 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/scummvm/scummvm_2026.1.0+dfsg.orig.tar.xz Result: main scummvm-2026.1.0/engines/twp/squirrel/sqstate.cpp:304:9: warning: Possible null pointer dereference: rlast [nullPointer] scummvm-2026.1.0/engines/twp/squirrel/sqstate.cpp:289:32: note: Assignment 'rlast=NULL', assigned value is 0 scummvm-2026.1.0/engines/twp/squirrel/sqstate.cpp:290:15: note: Assuming condition is false scummvm-2026.1.0/engines/twp/squirrel/sqstate.cpp:304:9: note: Null pointer dereference Explanation: The code sets t = resurrected and only enters the block when resurrected is non-null. So t is non-null on the first check of 'while(t)', the loop body runs at least once, and rlast is assigned a non-null t. The 'Assuming condition is false' path at line 290 cannot happen, so the possible null pointer dereference of rlast at line 304 is a false positive. The PR makes program memory keep the symbolic relation (t == resurrected, which is non-null), and removing this warning is correct. ---- 43 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sga/sga_0.10.15.orig.tar.gz Result: main sga-0.10.15/src/Thirdparty/stdaln.c:788:4: warning: If memory allocation fails, then there is a possible null pointer dereference: seq22 [nullPointerOutOfMemory] sga-0.10.15/src/Thirdparty/stdaln.c:776:32: note: Assuming allocation function fails sga-0.10.15/src/Thirdparty/stdaln.c:776:10: note: Assignment 'seq22=(unsigned char*)malloc(sizeof(unsigned char)*len2)', assigned value is 0 sga-0.10.15/src/Thirdparty/stdaln.c:788:4: note: Null pointer dereference Explanation: `seq22` comes from an unchecked `malloc` and is dereferenced in each of the three branches (lines 783, 788 and 793). The PR stops reporting the dereference at line 788 and reports the one at line 793 instead, in the `else` (amino acid) branch. Both are equally valid null-pointer-on-OOM dereferences of the same allocation, and the message is the same. The user still gets one true warning for `seq22`, only at a different branch, so the change does not matter. ---- 44 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/syslinux/syslinux_6.04~git20190206.bf6db5b4+dfsg1.orig.tar.xz Result: main syslinux-6.04~git20190206.bf6db5b4/core/fs/fat/fat.c:785:2: warning:inconclusive: If memory allocation fails, then there is a possible null pointer dereference: sbi [nullPointerOutOfMemory] syslinux-6.04~git20190206.bf6db5b4/core/fs/fat/fat.c:741:17: note: Assuming allocation function fails syslinux-6.04~git20190206.bf6db5b4/core/fs/fat/fat.c:741:17: note: Assignment 'sbi=malloc(sizeof(*sbi))', assigned value is 0 syslinux-6.04~git20190206.bf6db5b4/core/fs/fat/fat.c:785:2: note: Null pointer dereference Explanation: `sbi = malloc(...)` at line 741 is never checked for NULL. Line 785 writes `sbi->uuid` on every path where `fat_type` is not FAT32. That includes the FAT12 and FAT16 branches, so if malloc fails this is a real NULL dereference. The PR drops this warning, along with the ones at 779 and 782, and moves the 763 warning to 765. That pattern suggests the new range and constraint handling ends or changes the null-value forward analysis at the `clusters` if/else chain, instead of proving line 785 unreachable with a NULL `sbi`. A true (if repetitive) positive is lost. The impact is small, since earlier dereferences of `sbi` (e.g. line 749) probably still warn. ---- 45 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/v/vkmark/vkmark_2025.01.orig.tar.gz Result: main vkmark-2025.01/src/stb_image.h:4015:44: warning: Uninitialized variable: lencodes [uninitvar] vkmark-2025.01/src/stb_image.h:3992:13: note: Assuming condition is false vkmark-2025.01/src/stb_image.h:4015:44: note: Uninitialized variable: lencodes Explanation: The removed warning assumed the `while (n < ntot)` loop is skipped and then claimed `lencodes` is read uninitialized at line 4015. That path cannot reach line 4015. If the loop never runs, `n` stays 0. `ntot = hlit + hdist` is at least 258, so `n != ntot` holds and the function returns early at line 4014. On any path that does reach line 4015, `n == ntot`, so all `ntot` entries of `lencodes` (more than the `hlit` read there) were written by the loop. The PR's range/constraint tracking in program memory now lets Cppcheck see that this path is infeasible. A false positive was removed. ---- 46 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/w/wxwidgets3.2/wxwidgets3.2_3.2.11+dfsg1.orig.tar.xz Result: main wxWidgets-3.2.11/samples/scroll/scroll.cpp:343:31: style: Condition '200+100-scroll_x>0' is always true [knownConditionTrueFalse] wxWidgets-3.2.11/samples/scroll/scroll.cpp:329:29: note: Assuming that condition '0+100-scroll_x>0' is not redundant wxWidgets-3.2.11/samples/scroll/scroll.cpp:343:31: note: Condition '200+100-scroll_x>0' is always true Explanation: The two `if` statements are independent; the first has no return or else that would constrain `scroll_x` afterwards. `scroll_x` comes from `CalcUnscrolledPosition()` and can be any value, e.g. 400, which makes `300 - scroll_x > 0` false. Main's warning that `200+100-scroll_x>0` is always true, based on the earlier condition `0+100-scroll_x>0`, was a false positive. It likely came from the old program memory treating a range bound as a concrete value. The PR removes it. ---- 47 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/w/wxwidgets3.2/wxwidgets3.2_3.2.11+dfsg1.orig.tar.xz Result: your wxWidgets-3.2.11/src/x11/palette.cpp:100:25: style: Condition 'i 0)', the loop starts with i=j=0, so the first check 'i 0', and the inner while loops changing j) wrongly decides the loop condition is false. ---- 48 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xabacus/xabacus_8.5.1.orig.tar.bz2 Result: main xabacus-8.5.1/AbacusM.c:345:2: style: Variable 'absI' is assigned an expression that holds the same value. [redundantAssignment] xabacus-8.5.1/AbacusM.c:338:11: note: absI is assigned '(i>=0)?i:-i' here. xabacus-8.5.1/AbacusM.c:341:22: note: Assuming condition is false xabacus-8.5.1/AbacusM.c:345:2: note: Variable 'absI' is assigned an expression that holds the same value. Explanation: The warning itself is a true positive in both versions. absI is set to '(i>=0)?i:-i' at line 338, and neither i nor absI changes before the identical assignment at line 345. Only the note path differs: the PR adds 'Assuming condition is false' for 'n == 1' at line 343. That step is needed to reach line 345, so the explanation now covers both early returns and is more complete. This is a slight improvement in message accuracy. ---- 49 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/x/xpa/xpa_2.1.20.orig.tar.gz Result: your xpa-2.1.20/find.c:214:9: warning: If memory allocation fails, then there is a possible null pointer dereference: tbuf [nullPointerOutOfMemory] xpa-2.1.20/find.c:201:25: note: Assuming allocation function fails xpa-2.1.20/find.c:201:10: note: Assignment 'tbuf=(char*)xmalloc(len+1)', assigned value is 0 xpa-2.1.20/find.c:202:7: note: Assuming condition is false xpa-2.1.20/find.c:214:9: note: Null pointer dereference Explanation: The new warning says `tbuf` from `xmalloc(len+1)` may be NULL when it is read at line 214. In xpa, `xmalloc` is a wrapper that reports the error and exits or longjmps on failure, so it never returns NULL. On a real NULL, the earlier `strcpy(tbuf, ...)` at line 203 or 208 would already dereference it, so line 214 adds nothing. The warning probably appears because the PR now knows `len >= 1`, so the loop body runs. That understanding is not wrong, but the result is an extra report on an allocation that cannot fail in this project. The difference from main is a noisier, redundant and likely false out-of-memory warning, not a newly found bug. ---- 50 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xpenguins/xpenguins_3.2.4.orig.tar.gz Result: your xpenguins-3.2.4/src/ixpm.c:343:7: warning: If memory allocation fails, then there is a possible null pointer dereference: x [nullPointerOutOfMemory] xpenguins-3.2.4/src/ixpm.c:330:25: note: Assuming allocation function fails xpenguins-3.2.4/src/ixpm.c:330:11: note: Assignment '*out=(char**)malloc(sizeof(char*)*(n+3))', assigned value is 0 xpenguins-3.2.4/src/ixpm.c:331:13: note: x is assigned '*out' here. xpenguins-3.2.4/src/ixpm.c:343:7: note: Null pointer dereference Explanation: `*out = malloc(...)` is never checked, and `x = *out` is then indexed. At line 343, `x[j]` dereferences a null pointer if the allocation fails, so the new warning is a true positive. The loop is entered when `n > 0`. The only constraint is `assert(n+3>0)`, which gives `n > -3`. Main apparently treated that range condition as a single value (e.g. `n == -2`), which made `j