AI review of 2026-10-05_22-41-06-51b980ae69f3-results.txt PR: #8899 https://github.com/cppcheck-opensource/cppcheck/pull/8899 Tested: 51b980ae69f3ff5e29feb8120a9534284a2cad2b Merge base: eb4b6526b3502ee779a74019f814d45d890427ba Reviewed: 2026-10-07 21:06:51 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 241 in the report (random sample), 45 not reviewed: valueFlowMaxIterations Verdicts: 31 improvement, 6 neutral, 13 regression Tokens: 232287 input, 2440445 cache read, 49805 cache write, 32066 output The verdicts are written by AI and can be wrong. ---- 1 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/canu/canu_2.2+dfsg.orig.tar.xz Result: your canu-2.2/src/utility/src/parasail/cigar_template.c:116:5: warning: If memory allocation fails, then there is a possible null pointer dereference: cigar [nullPointerOutOfMemory] canu-2.2/src/utility/src/parasail/cigar_template.c:71:37: note: Assuming allocation function fails canu-2.2/src/utility/src/parasail/cigar_template.c:71:37: note: Assignment 'cigar=malloc(sizeof(struct parasail_cigar_t))', assigned value is 0 canu-2.2/src/utility/src/parasail/cigar_template.c:116:5: note: Null pointer dereference Explanation: The warning is the same true positive in both runs: cigar = malloc(...) at line 71 is not checked before cigar->seq is written at line 116. Only the trace changed. Main's trace had an irrelevant 'Assuming condition is true' step for the alphabet_aliases_ check at line 107, but the dereference happens whichever way that check goes. The new trace drops that step and is shorter and more accurate. ---- 2 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/cloudcompare/cloudcompare_2.13.2+git20240821+ds.orig.tar.xz Result: main cloudcompare-2.13.2+git20240821+ds/plugins/core/Standard/qCanupo/contrib/dlib/dlib/md5/md5_kernel_1.cpp:478:32: style: Variable 'end' can be declared as pointer to const [constVariablePointer] Explanation: `end` is only assigned `temp+56` or `temp+64` and then compared with `temp2` in `while (temp2 != end)`. Nothing is ever written through it, so declaring it `const unsigned char* end` is valid and the constVariablePointer style warning was a true positive. The PR only changes program-memory and range handling, which should not make this warning wrong. Losing it is a lost true positive, probably a side effect of changed valueflow results for this function. The exact mechanism is not visible, hence medium confidence. ---- 3 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/cloudcompare/cloudcompare_2.13.2+git20240821+ds.orig.tar.xz Result: main cloudcompare-2.13.2+git20240821+ds/plugins/core/Standard/qPoissonRecon/extern/PoissonRecon/ZLIB/gzio.c:477:14: style: Condition 'b==buf' is always true [knownConditionTrueFalse] cloudcompare-2.13.2+git20240821+ds/plugins/core/Standard/qPoissonRecon/extern/PoissonRecon/ZLIB/gzio.c:472:13: note: b is assigned 'buf' here. cloudcompare-2.13.2+git20240821+ds/plugins/core/Standard/qPoissonRecon/extern/PoissonRecon/ZLIB/gzio.c:473:23: note: Assuming condition is false cloudcompare-2.13.2+git20240821+ds/plugins/core/Standard/qPoissonRecon/extern/PoissonRecon/ZLIB/gzio.c:477:14: note: Condition 'b==buf' is always true Explanation: In gzgets(), `buf` is advanced by `*buf++` inside the while loop whenever gzread() returns a byte, so `b == buf` at line 477 is not always true. It is true only when nothing was read. The old warning came from treating the condition `len > 0` (from `len <= 0` being false) as the single value len == 1. With that value, `--len > 0` fails at once and buf never moves. The PR records such conditions as ranges (len >= 1) instead of a point value, which is exactly the bug its new tests target. So this false positive is gone. ---- 4 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/cloudcompare/cloudcompare_2.13.2+git20240821+ds.orig.tar.xz Result: your cloudcompare-2.13.2+git20240821+ds/plugins/core/Standard/qCanupo/contrib/dlib/tools/htmlify/to_xml.cpp:734:65: style: Condition 'class_stack.size()>0' is always true [knownConditionTrueFalse] cloudcompare-2.13.2+git20240821+ds/plugins/core/Standard/qCanupo/contrib/dlib/tools/htmlify/to_xml.cpp:718:56: note: Assuming that condition 'class_stack.size()>0' is not redundant cloudcompare-2.13.2+git20240821+ds/plugins/core/Standard/qCanupo/contrib/dlib/tools/htmlify/to_xml.cpp:722:60: note: Assuming condition is false cloudcompare-2.13.2+git20240821+ds/plugins/core/Standard/qCanupo/contrib/dlib/tools/htmlify/to_xml.cpp:734:65: note: Condition 'class_stack.size()>0' is always true Explanation: Line 734 sits inside the block guarded by `class_stack.size() > 0 && ...` at line 718, in the else branch of `class_stack.size() > 1`. Nothing changes `class_stack` between those checks, so the size is exactly 1 there and `class_stack.size() > 0` is always true. The PR now keeps the range constraint (size > 0) in program memory instead of losing it, so it finds this real redundant condition. This is a new true positive. ---- 5 / 50 ---- Verdict: REGRESSION (medium 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: `bin_of_previous_extremum` starts at 0. It is only updated inside the first loop when `number_of_extrema_profile` changes between adjacent bins. If that never happens (the first loop does not run because `number_of_bins <= 1`, or the profile is constant), it stays 0. The second loop then runs from 0 and reads `half_window_width[bin_of_previous_extremum-1]`, i.e. `half_window_width[-1]`. The path Cppcheck reported is feasible: for `number_of_bins == 1` the first loop is skipped while the second still runs once. So the negativeIndex warning is a true positive (an edge-case bug), and the PR losing it is a regression. ---- 6 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/d/dart-sdk/dart-sdk_3.13.4+dfsg1.orig.tar.xz Result: main dart-sdk-3.13.4+dfsg1/runtime/bin/uri.cc:152:31: error:inconclusive: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] dart-sdk-3.13.4+dfsg1/runtime/bin/uri.cc:123:43: note: Assuming allocation function fails dart-sdk-3.13.4+dfsg1/runtime/bin/uri.cc:123:36: note: Assignment 'buffer=static_cast(malloc(len*3+1))', assigned value is 0 dart-sdk-3.13.4+dfsg1/runtime/bin/uri.cc:152:31: note: Null pointer addition Explanation: In NormalizeEscapes, `buffer = malloc(len * 3 + 1)` is never checked for NULL. Inside the loop, line 152 does `buffer + buffer_pos` on that unchecked pointer, so the inconclusive nullPointerArithmeticOutOfMemory warning is a valid out-of-memory finding. The companion warning at line 158 is lost too, and that write runs unconditionally after the loop. Nothing in the code protects against a NULL result, so the PR's new range handling in ProgramMemory has dropped true positives, apparently by cutting the null value's path through this loop. ---- 7 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/d/dart-sdk/dart-sdk_3.13.4+dfsg1.orig.tar.xz Result: main dart-sdk-3.13.4+dfsg1/runtime/bin/uri.cc:158:3: warning:inconclusive: If memory allocation fails, then there is a possible null pointer dereference: buffer [nullPointerOutOfMemory] dart-sdk-3.13.4+dfsg1/runtime/bin/uri.cc:123:43: note: Assuming allocation function fails dart-sdk-3.13.4+dfsg1/runtime/bin/uri.cc:123:36: note: Assignment 'buffer=static_cast(malloc(len*3+1))', assigned value is 0 dart-sdk-3.13.4+dfsg1/runtime/bin/uri.cc:158:3: note: Null pointer dereference Explanation: Line 123 assigns `buffer = malloc(len*3+1)` and never checks it for NULL. Line 158, `buffer[buffer_pos] = '\0'`, runs on every path: even when the loop body never executes, it writes to `buffer[0]`. If the allocation fails, that write dereferences a null pointer, so the nullPointerOutOfMemory warning is a true positive. The PR changes how program memory handles loop and condition ranges, and that apparently stopped the null value from reaching this point (the related warning at line 152 also disappeared). Losing this valid warning is a regression. ---- 8 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/d/dart-sdk/dart-sdk_3.13.4+dfsg1.orig.tar.xz Result: main dart-sdk-3.13.4+dfsg1/third_party/pkg/native/pkgs/code_assets/example/sqlite_no_link/third_party/sqlite/sqlite3.c:43970:13: style: Condition 'bUnlock' is always true [knownConditionTrueFalse] dart-sdk-3.13.4+dfsg1/third_party/pkg/native/pkgs/code_assets/example/sqlite_no_link/third_party/sqlite/sqlite3.c:43951:23: note: Assignment 'bUnlock=1', assigned value is 1 dart-sdk-3.13.4+dfsg1/third_party/pkg/native/pkgs/code_assets/example/sqlite_no_link/third_party/sqlite/sqlite3.c:43970:13: note: Condition 'bUnlock' is always true Explanation: `bUnlock` starts at 1 but is set to 0 inside `if( aLock[ofst]>1 )`, after the assert `aLock[ofst]>=1`. So the condition at 43970 is not always true, and main's knownConditionTrueFalse warning was a false positive. Main recorded the condition `aLock[ofst]>=1` as the point value 1, which made `aLock[ofst]>1` look always false. The PR records such conditions as ranges instead (the same pattern as its new 'length > 1' test), so this false positive is gone. ---- 9 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/d/dc3dd/dc3dd_7.3.1.orig.tar.xz Result: main dc3dd-7.3.1/lib/sig2str.c:333:20: style: Condition 'delta' is always true [knownConditionTrueFalse] dc3dd-7.3.1/lib/sig2str.c:325:17: note: Assignment 'rtmax=0-1', assigned value is -1 dc3dd-7.3.1/lib/sig2str.c:327:38: note: Assuming that condition 'signum<=rtmax' is not redundant dc3dd-7.3.1/lib/sig2str.c:332:21: note: Assignment 'delta=signum-rtmin', assigned value is symbolic=signum dc3dd-7.3.1/lib/sig2str.c:333:20: note: Condition 'delta' is always true Explanation: The same 'Condition delta is always true' warning at sig2str.c:333 is still reported, so this is not a removal. Only the note trace changed. With the fallback macros SIGRTMIN=0 and SIGRTMAX=-1, the check at line 327 always returns, so line 333 is unreachable in this configuration. The warning is equally vacuous before and after the PR. The old trace (rtmax=-1, so signum<=-1, so delta=signum is nonzero) explains the claim a bit more coherently than the new one ('greater than symbolic=rtmin-1'). Still, the reported issue is identical and matters the same to users either way. ---- 10 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/d/dc3dd/dc3dd_7.3.1.orig.tar.xz Result: main getdate.y:1055:17: style: Condition 'sign<0' is always false [knownConditionTrueFalse] getdate.y:1027:17: note: Assuming that condition 'sign<0' is not redundant getdate.y:1041:18: note: Assuming condition is false getdate.y:1055:17: note: Condition 'sign<0' is always false Explanation: The removed warning claimed that the second `sign < 0` check (after the `value != value1` check) is always false. That is wrong. When `sign < 0`, the code sets `s = -value` and `value1 = -s`, so `value1 == value` and the early `return '?'` is not taken. Execution then reaches the later `sign < 0` check with `sign` still negative. Nothing between the two checks changes `sign`, so the condition can be true. Main's reasoning chain assumed the `value != value1` check was false and wrongly concluded `sign >= 0`. The PR removes this false positive. ---- 11 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/e/efl/efl_1.28.1.orig.tar.xz Result: your efl-1.28.1/src/lib/eina/eina_file_common.c:132:23: warning: Either the condition '!result' is redundant or there is possible null pointer dereference: p. [nullPointerRedundantCheck] efl-1.28.1/src/lib/eina/eina_file_common.c:125:8: note: Assuming that condition '!result' is not redundant efl-1.28.1/src/lib/eina/eina_file_common.c:122:8: note: Assignment 'p=result', assigned value is 0 efl-1.28.1/src/lib/eina/eina_file_common.c:125:8: note: Assuming condition is false efl-1.28.1/src/lib/eina/eina_file_common.c:132:23: note: Null pointer dereference Explanation: The function sets `p = result` and then returns early when `!result` is true. So when the condition is false, `result`, and therefore `p`, is non-null at the first `strchr(p, '/')` on line 132. In later iterations `p` is either the non-null result of `strchr` (the loop ends when it is null) or `q`, which is never null. The warning's own path is contradictory: it claims `p` is 0 while also assuming the null check is false. This is a new false positive. ---- 12 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/g2clib/g2clib_2.3.0.orig.tar.xz Result: your g2clib-2.3.0/src/g2ccsv.c:262:28: warning: If memory allocation fails, then there is a possible null pointer dereference: key [nullPointerOutOfMemory] g2clib-2.3.0/src/g2ccsv.c:256:29: note: Assuming allocation function fails g2clib-2.3.0/src/g2ccsv.c:256:29: note: Assignment 'key=strdup((const char*)tmp)', assigned value is 0 g2clib-2.3.0/src/g2ccsv.c:246:22: note: Assuming condition is false g2clib-2.3.0/src/g2ccsv.c:262:28: note: Null pointer dereference Explanation: In the else branch, `key = strdup(tmp)` at line 256 is never checked for NULL. On the first inner-loop iteration `i` is 0, so `strlen(key)` at line 262 runs right away. If `strdup` fails, that is a NULL dereference, so this nullPointerOutOfMemory warning is a true positive. The PR's better range handling in the program memory appears to let Cppcheck see that this path is reachable, which main missed. A real (if low-severity) out-of-memory issue is now reported. ---- 13 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mapserver/mapserver_8.6.6.orig.tar.gz Result: your mapserver-8.6.6/src/renderers/agg/include/agg_span_image_filter_rgba.h:319:33: style: Condition 'x_lr<=maxx' is always true [knownConditionTrueFalse] mapserver-8.6.6/src/renderers/agg/include/agg_span_image_filter_rgba.h:299:29: note: Assuming that condition 'x_lr>maxx' is not redundant mapserver-8.6.6/src/renderers/agg/include/agg_span_image_filter_rgba.h:319:33: note: Condition 'x_lr<=maxx' is always true Explanation: Line 319 sits in the else branch of the `if` at lines 298-299, so `x_lr > maxx` is false there and `x_lr <= maxx` holds. `x_lr` is not modified between the two lines: only `x_hr` and `y_hr` are masked. The condition at line 319 is therefore really always true. The redundancy comes from AGG's copy-paste pattern; the same check matters at line 340, after `x_lr++`. This is a correct new knownConditionTrueFalse warning, consistent with the PR's better tracking of ranges from conditions. ---- 14 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nanopolish/nanopolish_0.14.0.orig.tar.gz Result: main nanopolish-0.14.0/src/thirdparty/stdaln.c:786:4: warning: If memory allocation fails, then there is a possible null pointer dereference: seq11 [nullPointerOutOfMemory] nanopolish-0.14.0/src/thirdparty/stdaln.c:775:32: note: Assuming allocation function fails nanopolish-0.14.0/src/thirdparty/stdaln.c:775:10: note: Assignment 'seq11=(unsigned char*)malloc(sizeof(unsigned char)*len1)', assigned value is 0 nanopolish-0.14.0/src/thirdparty/stdaln.c:786:4: note: Null pointer dereference Explanation: `seq11` is allocated with `malloc` and is never checked for NULL. It is then written to in each of the three mutually exclusive branches selected by `ap->row` (lines 781, 786 and 791). Both versions report one true nullPointerOutOfMemory for `seq11`. The pull request only moves the reported dereference from the 16-nucleotide branch (786) to the amino-acid branch (791). Both locations are reachable dereferences of a possibly-null pointer, so users get an equally valid warning about the same missing NULL check. ---- 15 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nanopolish/nanopolish_0.14.0.orig.tar.gz Result: main nanopolish-0.14.0/src/thirdparty/stdaln.c:788:4: warning: If memory allocation fails, then there is a possible null pointer dereference: seq22 [nullPointerOutOfMemory] nanopolish-0.14.0/src/thirdparty/stdaln.c:776:32: note: Assuming allocation function fails nanopolish-0.14.0/src/thirdparty/stdaln.c:776:10: note: Assignment 'seq22=(unsigned char*)malloc(sizeof(unsigned char)*len2)', assigned value is 0 nanopolish-0.14.0/src/thirdparty/stdaln.c:788:4: note: Null pointer dereference Explanation: The `nullPointerOutOfMemory` warning for `seq22` (unchecked `malloc` at line 776) moved from line 788, the 16-nucleotide branch, to line 793, the amino-acid branch. Both lines dereference `seq22` without a NULL check, and both branches are reachable. The issue is the same true positive either way; only the dereference site Cppcheck picks to report changed. This does not matter to users. ---- 16 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nanopolish/nanopolish_0.14.0.orig.tar.gz Result: your nanopolish-0.14.0/src/thirdparty/stdaln.c:793:4: warning: If memory allocation fails, then there is a possible null pointer dereference: seq22 [nullPointerOutOfMemory] nanopolish-0.14.0/src/thirdparty/stdaln.c:776:32: note: Assuming allocation function fails nanopolish-0.14.0/src/thirdparty/stdaln.c:776:10: note: Assignment 'seq22=(unsigned char*)malloc(sizeof(unsigned char)*len2)', assigned value is 0 nanopolish-0.14.0/src/thirdparty/stdaln.c:793:4: note: Null pointer dereference Explanation: `seq22 = malloc(len2)` is never checked for NULL, and every branch of the `ap->row` if/else-if/else chain writes to `seq22[j]`. The out-of-memory null dereference is therefore real in all three branches. Main reported it in the 16-nucleotide branch (line 788); the PR reports it in the amino-acid branch (line 793). The same is true for `seq11` (786 to 791). It is the same true positive with a different but equally valid location, so nothing changes for users. ---- 17 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/n/netcdf/netcdf_4.10.1.orig.tar.gz Result: your netcdf-c-4.10.1/ncdump/tst_vlen_data.c:97:4: warning:inconclusive: If memory allocation fails, then there is a possible null pointer dereference: array [nullPointerOutOfMemory] netcdf-c-4.10.1/ncdump/tst_vlen_data.c:87:29: note: Assuming allocation function fails netcdf-c-4.10.1/ncdump/tst_vlen_data.c:87:12: note: Assignment 'array=(float**)malloc(5*sizeof(float*))', assigned value is 0 netcdf-c-4.10.1/ncdump/tst_vlen_data.c:92:20: note: Assuming condition is false netcdf-c-4.10.1/ncdump/tst_vlen_data.c:97:4: note: Null pointer dereference Explanation: Line 87 allocates `array`, and line 88 checks `if(array == NULL) ERR;`. In netcdf's test headers, `ERR` normally returns from the function, so `array` cannot be NULL at line 97 and the warning is a false positive either way. Cppcheck evidently does not see `ERR` as leaving the function: main already reported the same dereference, only as nullPointerRedundantCheck based on the line 88 check. The PR keeps the same path to the same location and only changes the label to nullPointerOutOfMemory, now based on malloc failing. Both messages are inconclusive and describe the same NULL path, so neither is clearly more accurate. Nothing was added or removed for users. ---- 18 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/n/nghttp2/nghttp2_1.70.0.orig.tar.gz Result: main nghttp2-1.70.0/third-party/mruby/mrbgems/mruby-io/src/io.c:2062:9: style: Condition 'limit_given' is always false [knownConditionTrueFalse] nghttp2-1.70.0/third-party/mruby/mrbgems/mruby-io/src/io.c:2038:7: note: Assuming that condition 'limit_given' is not redundant nghttp2-1.70.0/third-party/mruby/mrbgems/mruby-io/src/io.c:2062:9: note: Condition 'limit_given' is always false Explanation: `limit_given` is not changed anywhere in the loop. When it is true and `limit > 0`, execution passes the checks at line 2038 and enters the loop. So the condition at line 2062 can be true, and "always false" was a false positive. It likely came from main's program memory treating a range condition such as `limit > 0` as a single value. The PR records such conditions as ranges, which removes this false positive. ---- 19 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nyquist/nyquist_3.24+ds.orig.tar.xz Result: main nyquist-3.24+ds/ffts/src/fft2d.c:113:16: warning: Either the condition 'M2>0' is redundant or the array 'Array2d[64]' is accessed at index 64, which is out of bounds. [arrayIndexOutOfBoundsCond] nyquist-3.24+ds/ffts/src/fft2d.c:103:7: note: Assuming that condition 'M2>0' is not redundant nyquist-3.24+ds/ffts/src/fft2d.c:113:16: note: Array index out of bounds Explanation: In ifft2d(), M2 is a function parameter, and line 103 only checks that it is greater than 0. Nothing in this function makes M2 equal to 64. Array2d has 64 entries (8*sizeof(long)), and the init code only allocates entries for log2 sizes below that bound. So the claim that 'M2>0' leads to Array2d[64] being accessed does not follow from the code. The same warning disappeared at every analogous site in fft2d.c, which points to a systematic false positive. The PR changes how conditions like 'x > 0' are stored in program memory: they are now recorded as a range instead of one concrete value. That is the kind of fix that removes such a spurious pairing of condition and index, so dropping this warning is most likely a false positive removed. ---- 20 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nyquist/nyquist_3.24+ds.orig.tar.xz Result: main nyquist-3.24+ds/ffts/src/fft2d.c:203:15: warning: Either the condition 'M3>0' is redundant or the array 'Array2d[64]' is accessed at index 64, which is out of bounds. [arrayIndexOutOfBoundsCond] nyquist-3.24+ds/ffts/src/fft2d.c:178:7: note: Assuming that condition 'M3>0' is not redundant nyquist-3.24+ds/ffts/src/fft2d.c:203:15: note: Array index out of bounds Explanation: In fft3d(), Array2d[M3] is used inside the `if ((M3>0)&&(M2>0)&&(M>0))` branch. The condition `M3>0` only says M3 is at least 1. It gives no reason to think M3 could be 64; M3 is the log2 of an FFT size and is also used in shifts (POW2), so it is far below 64 in practice. The old warning tied the index value 64 to the condition `M3>0`, which looks like the old program memory turning a bounded condition value into a concrete point value. The PR now records a condition like `x > 3` as a range (values up to 3 are impossible) instead of a single value. That removes this spurious index and the matching warnings for M2 across fft2d.c. This is very likely a removed false positive. ---- 21 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nyquist/nyquist_3.24+ds.orig.tar.xz Result: main nyquist-3.24+ds/ffts/src/fft2d.c:242:17: warning: Either the condition 'M2>0' is redundant or the array 'Array2d[64]' is accessed at index 64, which is out of bounds. [arrayIndexOutOfBoundsCond] nyquist-3.24+ds/ffts/src/fft2d.c:229:15: note: Assuming that condition 'M2>0' is not redundant nyquist-3.24+ds/ffts/src/fft2d.c:242:17: note: Array index out of bounds Explanation: In ifft3d, M2 is a long parameter giving the log2 of the row count. It is only known to be > 0 inside the branch at line 229. Nothing in the code suggests M2 could be 64, which is what an out-of-bounds index on Array2d[64] would need. The condition 'M2>0' gives a lower bound only, so it cannot imply index 64. Main's warning comes from the program memory treating the range from a condition as a concrete value, which the PR fixes. The same warning disappearing across all the fft2d functions points to this being a false positive that was removed. ---- 22 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nyquist/nyquist_3.24+ds.orig.tar.xz Result: main nyquist-3.24+ds/ffts/src/fft2d.c:254:16: warning: Either the condition 'M3>0' is redundant or the array 'Array2d[64]' is accessed at index 64, which is out of bounds. [arrayIndexOutOfBoundsCond] nyquist-3.24+ds/ffts/src/fft2d.c:229:7: note: Assuming that condition 'M3>0' is not redundant nyquist-3.24+ds/ffts/src/fft2d.c:254:16: note: Array index out of bounds Explanation: Array2d has 64 entries and is indexed by M3, the log2 of the transform size. The guard 'M3>0' only says M3 >= 1. It gives no reason to think M3 can be 64, so the 'Either the condition is redundant or index 64' warning cannot follow from that condition and is a false positive. All the similar fft2d.c warnings tied to 'M2>0' or 'M3>0' disappear together. That fits the PR's change: a range condition is now recorded as a range in program memory instead of a point value, which removes the bogus out-of-bounds inference. ---- 23 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nyquist/nyquist_3.24+ds.orig.tar.xz Result: main nyquist-3.24+ds/ffts/src/fft2d.c:255:3: warning: Either the condition 'M3>0' is redundant or the array 'Array2d[64]' is accessed at index 64, which is out of bounds. [arrayIndexOutOfBoundsCond] nyquist-3.24+ds/ffts/src/fft2d.c:229:7: note: Assuming that condition 'M3>0' is not redundant nyquist-3.24+ds/ffts/src/fft2d.c:255:3: note: Array index out of bounds Explanation: Line 255 indexes `Array2d[M3]`, guarded by `if((M3>0)&&...)`. That condition only gives a lower bound on M3. It says nothing about M3 reaching 64, the size of `Array2d`. The warning tied the condition 'M3>0' to index 64, so the condition was wrongly turned into a concrete out-of-bounds value. The PR changes how program memory handles ranges from conditions: 'x > 3' is now kept as a range instead of a single value. With that change, the spurious link is gone. The same warning disappeared consistently across fft2d.c for both M2 and M3. This is a false positive removed. ---- 24 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nyquist/nyquist_3.24+ds.orig.tar.xz Result: main nyquist-3.24+ds/ffts/src/fft2d.c:287:3: warning: Either the condition 'M2>0' is redundant or the array 'Array2d[64]' is accessed at index 64, which is out of bounds. [arrayIndexOutOfBoundsCond] nyquist-3.24+ds/ffts/src/fft2d.c:284:7: note: Assuming that condition 'M2>0' is not redundant nyquist-3.24+ds/ffts/src/fft2d.c:287:3: note: Array index out of bounds Explanation: In rfft2d, M2 is a plain function parameter: the log2 of the row count. Line 287 only runs inside `if((M2>0)&&(M>0))`, and nothing visible gives M2 the value 64. The condition `M2>0` cannot make index 64 more or less likely, so the claimed link between the condition and an out-of-bounds index is spurious. The PR changes how condition ranges are stored in program memory: `x > 3` is now kept as a range instead of being treated like a single value. That is the kind of mistake that could create a bogus extreme value tied to `M2>0`. The same pattern disappears from every function in fft2d.c, which fits a systematic false positive. Removing it is likely an improvement. Confidence is not high because the origin of the value 64 is not shown. ---- 25 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nyquist/nyquist_3.24+ds.orig.tar.xz Result: main nyquist-3.24+ds/ffts/src/fft2d.c:334:3: warning: Either the condition 'M2>0' is redundant or the array 'Array2d[64]' is accessed at index 64, which is out of bounds. [arrayIndexOutOfBoundsCond] nyquist-3.24+ds/ffts/src/fft2d.c:332:7: note: Assuming that condition 'M2>0' is not redundant nyquist-3.24+ds/ffts/src/fft2d.c:334:3: note: Array index out of bounds Explanation: In rifft2d, M2 is a log2 FFT size passed in by the caller and is used to index Array2d[M2]. The only guard is `if((M2>0)&&(M>0))`. A lower bound M2>0 says nothing about M2 reaching 64, so 'Either M2>0 is redundant or index 64 is out of bounds' does not follow from the code. Before this PR, the program memory treated a bounded condition like `M2>0` as a concrete value; the PR records it as a range constraint instead. That is the kind of change that would remove this spurious conditional out-of-bounds warning, and the same disappearance happens across all the matching fft2d.c warnings. This is likely a false positive removed. ---- 26 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nyquist/nyquist_3.24+ds.orig.tar.xz Result: main nyquist-3.24+ds/ffts/src/fft2d.c:336:39: warning: Either the condition 'M2>0' is redundant or the array 'Array2d[64]' is accessed at index 64, which is out of bounds. [arrayIndexOutOfBoundsCond] nyquist-3.24+ds/ffts/src/fft2d.c:332:7: note: Assuming that condition 'M2>0' is not redundant nyquist-3.24+ds/ffts/src/fft2d.c:336:39: note: Array index out of bounds Explanation: In rifft2d, M2 is a plain function parameter: the log2 of the number of rows. The only facts the code gives about it are the conditions `M2>0` and `M>0`. Nothing makes M2 equal to 64, and a value of 64 would mean a 2^64-row FFT, which is not realistic. The removed warning claims that the condition `M2>0` implies an access to `Array2d[64]`. That matches the bug this PR fixes, where a range from a condition was treated as a concrete or wrong value. The same warning disappears consistently at about 28 similar sites in fft2d.c. Removing this false positive is an improvement. ---- 27 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nyquist/nyquist_3.24+ds.orig.tar.xz Result: main nyquist-3.24+ds/ffts/src/fft2d.c:337:3: warning: Either the condition 'M2>0' is redundant or the array 'Array2d[64]' is accessed at index 64, which is out of bounds. [arrayIndexOutOfBoundsCond] nyquist-3.24+ds/ffts/src/fft2d.c:332:7: note: Assuming that condition 'M2>0' is not redundant nyquist-3.24+ds/ffts/src/fft2d.c:337:3: note: Array index out of bounds Explanation: In rifft2d, M2 is the log2 of the row count. The only fact the code gives about it is the guard 'M2>0' at line 332. That guard says nothing about M2 being 64, so it cannot show that Array2d[M2] (array size 64) is indexed at 64. The old warning came from programmemory treating a bound from a condition as the variable's value. The PR fixes exactly this by recording 'M2>0' as a range constraint. The same spurious warning disappears consistently across every function in fft2d.c. This is a false positive removed. ---- 28 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nyquist/nyquist_3.24+ds.orig.tar.xz Result: main nyquist-3.24+ds/ffts/src/fft2d.c:86:15: warning: Either the condition 'M2>0' is redundant or the array 'Array2d[64]' is accessed at index 64, which is out of bounds. [arrayIndexOutOfBoundsCond] nyquist-3.24+ds/ffts/src/fft2d.c:76:7: note: Assuming that condition 'M2>0' is not redundant nyquist-3.24+ds/ffts/src/fft2d.c:86:15: note: Array index out of bounds Explanation: Inside `if((M2>0)&&(M>0))`, the code indexes `Array2d[M2]` (64 entries), where M2 is the log2 of the row count. The condition `M2>0` only gives a lower bound. Nothing in the code suggests M2 can reach 64, which would mean 2^64 rows. The old ProgramMemory stored a bounded condition value as if it were a concrete point value, which produced spurious index values like this one. The PR now records conditions as impossible ranges instead, so this arrayIndexOutOfBoundsCond warning disappears. It was a false positive, so removing it is an improvement. ---- 29 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pcb/pcb_4.2.2.orig.tar.gz Result: your pcb-4.2.2/src/rtree.c:1060:23: warning: If memory allocation fails, then there is a possible null pointer dereference: rtree [nullPointerOutOfMemory] pcb-4.2.2/src/rtree.c:432:29: note: Assuming allocation function fails pcb-4.2.2/src/rtree.c:432:11: note: Assignment 'rtree=(struct rtree_t*)calloc(1,sizeof(*rtree))', assigned value is 0 pcb-4.2.2/src/rtree.c:442:23: note: Calling function 'r_insert_entry', 1st argument 'rtree' value is 0 pcb-4.2.2/src/rtree.c:1060:23: note: Null pointer dereference Explanation: The new warnings say that if `calloc` fails in `r_create_tree` (line 432), the null `rtree` reaches `r_insert_entry` and is dereferenced there. In that function, `rtree` is a null value carried in from the caller. That function very likely writes `rtree->root = node` right after the calloc and before the insert loop at line 442, which the shown lines do not include. If so, a failed allocation crashes at that earlier write, and the path into `r_insert_entry` with a null `rtree` cannot happen. These seven reports in the callee would then add nothing: at best they repeat the out-of-memory issue at the wrong place, and the path they describe does not exist. They probably appear because the PR's new range handling now judges the insert loop (`i < N`, after `assert(N >= 0)`) differently. The result is extra noisy warnings rather than a real new defect. ---- 30 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pnetcdf/pnetcdf_1.15.1.orig.tar.xz Result: your pnetcdf-1.15.1/examples/C/mput.c:173:25: warning: If memory allocation fails, then there is a possible null pointer dereference: starts [nullPointerOutOfMemory] pnetcdf-1.15.1/examples/C/mput.c:168:42: note: Assuming allocation function fails pnetcdf-1.15.1/examples/C/mput.c:168:21: note: Assignment 'starts=(MPI_Offset**)malloc(sizeof(MPI_Offset*)*num_reqs)', assigned value is 0 pnetcdf-1.15.1/examples/C/mput.c:173:25: note: Null pointer dereference Explanation: Inside `if (num_reqs > 0)`, `starts` comes from an unchecked `malloc`. The loop `for (i=1; i 0` made the program memory treat `num_reqs` as exactly 1, so the loop looked dead and no warning was given there. The PR keeps `num_reqs > 0` as a range, so the loop body is now correctly seen as reachable. If `malloc` fails, `starts` is NULL and `starts[i-1]` is a real null dereference, so the new warning is valid. It is somewhat redundant, since `starts[0]` at line 170 is dereferenced first, but it is not wrong. ---- 31 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pnetcdf/pnetcdf_1.15.1.orig.tar.xz Result: your pnetcdf-1.15.1/examples/C/put_varn_int.c:164:13: warning: If memory allocation fails, then there is a possible null pointer dereference: starts [nullPointerOutOfMemory] pnetcdf-1.15.1/examples/C/put_varn_int.c:159:42: note: Assuming allocation function fails pnetcdf-1.15.1/examples/C/put_varn_int.c:159:21: note: Assignment 'starts=(MPI_Offset**)malloc(sizeof(MPI_Offset*)*num_reqs)', assigned value is 0 pnetcdf-1.15.1/examples/C/put_varn_int.c:164:13: note: Null pointer dereference Explanation: Line 159 calls malloc for `starts` and never checks the result. Line 164 then dereferences it inside the loop `for (i=1; i 0`. Before this PR, the program memory recorded the condition `num_reqs > 0` as the single value `num_reqs == 1`. The loop then looked like it never ran, so the dereferences inside it were not checked. The PR records the condition as a range instead, so the loop body is now seen as reachable (num_reqs is 4, 5 or 6 here). If the allocation fails, `starts[i-1]` really is a NULL dereference. The new warning is a true positive. It is somewhat redundant, since line 161 already dereferences `starts` first, but the finding itself is correct. ---- 32 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pnetcdf/pnetcdf_1.15.1.orig.tar.xz Result: your pnetcdf-1.15.1/examples/CXX/put_varn_float.cpp:120:17: warning: If memory allocation fails, then there is a possible null pointer dereference: starts [nullPointerOutOfMemory] pnetcdf-1.15.1/examples/CXX/put_varn_float.cpp:117:45: note: Assuming allocation function fails pnetcdf-1.15.1/examples/CXX/put_varn_float.cpp:117:25: note: Assignment 'starts=(MPI_Offset**)std::malloc(sizeof(MPI_Offset*)*num_reqs)', assigned value is 0 pnetcdf-1.15.1/examples/CXX/put_varn_float.cpp:120:17: note: Null pointer dereference Explanation: Line 117 assigns `starts` from an unchecked `malloc`, and lines 118–120 dereference it, so a NULL return would crash in the loop at line 120. Before the PR, the condition `num_reqs > 0` was apparently treated as `num_reqs == 1`. That made the loop `for (i=1; i 0` as a range, so the loop body is now seen as reachable. The new nullPointerOutOfMemory warning on `starts[i]`/`starts[i-1]` is a true positive under the unchecked-malloc assumption, though it repeats the problem already present at line 118. ---- 33 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pnetcdf/pnetcdf_1.15.1.orig.tar.xz Result: your pnetcdf-1.15.1/examples/CXX/put_varn_int.cpp:130:29: warning: If memory allocation fails, then there is a possible null pointer dereference: starts [nullPointerOutOfMemory] pnetcdf-1.15.1/examples/CXX/put_varn_int.cpp:125:46: note: Assuming allocation function fails pnetcdf-1.15.1/examples/CXX/put_varn_int.cpp:125:25: note: Assignment 'starts=(MPI_Offset**)std::malloc(sizeof(MPI_Offset*)*num_reqs)', assigned value is 0 pnetcdf-1.15.1/examples/CXX/put_varn_int.cpp:130:29: note: Null pointer dereference Explanation: `starts` is assigned from an unchecked `malloc` at line 125, and `starts[i-1]` / `starts[i]` are dereferenced in the loop at line 130. That loop runs whenever `num_reqs > 1` (`num_reqs` is 4–6 here). Before the PR, the condition `num_reqs > 0` was stored in program memory as the value `num_reqs == 1`, so `i 0` as a range, so the body is correctly seen as reachable. If allocation fails, `starts` is NULL and is dereferenced there. This is a genuine nullPointerOutOfMemory finding, though it is somewhat redundant with the earlier dereference at line 127. ---- 34 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/python-awkward/python-awkward_2.9.0.orig.tar.gz Result: your awkward-2.9.0/studies/awkward-forth/virtual-machine-no-vtables.cpp:1843:15: warning: Array index -1 is out of bounds. [negativeContainerIndex] awkward-2.9.0/studies/awkward-forth/virtual-machine-no-vtables.cpp:1841:35: note: Assignment 'variable_index=-1', assigned value is -1 awkward-2.9.0/studies/awkward-forth/virtual-machine-no-vtables.cpp:1843:15: note: Negative array index Explanation: `variable_index` starts at -1. The loop condition `-1 < (int64_t)variable_names_.size()` is always true, because the size is never negative. So the first iteration always evaluates `variable_names_[-1]` before any increment. That is a real out-of-bounds access: the loop should start at 0. The new negativeContainerIndex warning is a true positive that main missed. ---- 35 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/python-awkward/python-awkward_2.9.0.orig.tar.gz Result: your awkward-2.9.0/studies/awkward-forth/virtual-machine.cpp:1905:15: warning: Array index -1 is out of bounds. [negativeContainerIndex] awkward-2.9.0/studies/awkward-forth/virtual-machine.cpp:1903:32: note: Assignment 'input_index=-1', assigned value is -1 awkward-2.9.0/studies/awkward-forth/virtual-machine.cpp:1905:15: note: Negative array index Explanation: `input_index` is initialized to -1. The first loop iteration checks `-1 < size()`, which is true, and then reads `input_names_[-1]`. This is a real out-of-bounds access (a bug in the study code; the loop should start at 0). The new warning is a true positive that main missed. ---- 36 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/q/qemu/qemu_11.1.2+ds.orig.tar.xz Result: your qemu-11.1.2/roms/u-boot/arch/x86/cpu/irq.c:136:35: warning: Uninitialized variable: slot [uninitvar] qemu-11.1.2/roms/u-boot/arch/x86/cpu/irq.c:282:26: note: Calling function 'check_dup_entry', 1st argument 'slot_base' value is qemu-11.1.2/roms/u-boot/arch/x86/cpu/irq.c:127:26: note: Assignment 'slot=slot_base', assigned value is qemu-11.1.2/roms/u-boot/arch/x86/cpu/irq.c:130:16: note: Assuming condition is false qemu-11.1.2/roms/u-boot/arch/x86/cpu/irq.c:136:35: note: Uninitialized variable: slot Explanation: In check_dup_entry() the loop runs from i = 0 to entry_num, and the function returns NULL when i == entry_num, else slot. If the loop condition is false on entry (entry_num <= 0 in practice, since the caller passes the counter irq_entries, which starts at 0), then i == entry_num and NULL is returned, so 'slot' is never read on that path. Beyond that, 'slot' is only a copy of the 'slot_base' pointer, and the caller's pointer is set (presumably from an allocation; line 282 is not shown). Returning that pointer is not a read of uninitialized data. The new warning appears to come from the PR's reworked ternary/condition handling: the knowledge that i == entry_num when the loop is skipped is lost. This is a new false positive. ---- 37 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/q/qtads/qtads_3.4.0+dfsg.orig.tar.xz Result: main qtads-3.4.0/tads2/osnoui.c:1309:14: warning: If memory allocation fails, then there is a possible null pointer dereference: ctx [nullPointerOutOfMemory] qtads-3.4.0/tads2/osnoui.c:1299:53: note: Assuming allocation function fails qtads-3.4.0/tads2/osnoui.c:1299:26: note: Assignment 'ctx=S_isaacctx=(struct isaacctx*)malloc(sizeof(struct isaacctx))', assigned value is 0 qtads-3.4.0/tads2/osnoui.c:1298:28: note: Assuming condition is true qtads-3.4.0/tads2/osnoui.c:1309:14: note: Null pointer dereference Explanation: In isaac_init(), `ctx = S_isaacctx = malloc(...)` is never checked for NULL. On the first call `inited` is FALSE, so execution reaches `ctx->a = ctx->b = ctx->c = 0;` at line 1309. If malloc fails there, ctx is NULL and is dereferenced. The nullPointerOutOfMemory warning is therefore a true positive. The PR's program-memory changes drop this warning, along with the related ones on lines 1309–1311, so a valid finding is lost. ---- 38 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/q/qtads/qtads_3.4.0+dfsg.orig.tar.xz Result: main qtads-3.4.0/tads2/osnoui.c:1309:23: warning: If memory allocation fails, then there is a possible null pointer dereference: ctx [nullPointerOutOfMemory] qtads-3.4.0/tads2/osnoui.c:1299:53: note: Assuming allocation function fails qtads-3.4.0/tads2/osnoui.c:1299:26: note: Assignment 'ctx=S_isaacctx=(struct isaacctx*)malloc(sizeof(struct isaacctx))', assigned value is 0 qtads-3.4.0/tads2/osnoui.c:1298:28: note: Assuming condition is true qtads-3.4.0/tads2/osnoui.c:1309:23: note: Null pointer dereference Explanation: When S_isaacctx is null, ctx gets the result of malloc() at line 1299, and that result is never checked. On the first call `inited` is FALSE, so the early return at line 1305 is not taken. If malloc fails, `ctx->c` at line 1309 dereferences a null pointer. The nullPointerOutOfMemory warning is therefore a true positive. The PR removes it along with the other warnings on lines 1309-1311. This looks like the new range/constraint handling in the program memory wrongly treating the null path as unreachable, so it is a regression. ---- 39 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/redisearch/redisearch_1.2.2.orig.tar.gz Result: main RediSearch-1.2.2/src/doc_table.c:413:7: warning: If memory allocation fails, then there is a possible null pointer dereference: dmd [nullPointerOutOfMemory] RediSearch-1.2.2/src/doc_table.c:399:40: note: Assuming allocation function fails RediSearch-1.2.2/src/doc_table.c:399:40: note: Assignment 'dmd=calloc(1,sizeof(struct RSDocumentMetadata))', assigned value is 0 RediSearch-1.2.2/src/doc_table.c:401:16: note: Assuming condition is true RediSearch-1.2.2/src/doc_table.c:413:7: note: Null pointer dereference Explanation: The nullPointerOutOfMemory warning at line 413 is still reported (dmd from rm_calloc/calloc is dereferenced without a NULL check). Only the 'Assuming condition is true' note changed. Main pointed at line 401 (`encver < INDEX_MIN_BINKEYS_VERSION`), which has nothing to do with reaching line 413. The PR points at line 412 (`encver > 1`), the condition that actually guards the dereference at 413. The warning itself is unchanged and the trace note is now more accurate. ---- 40 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/redisearch/redisearch_1.2.2.orig.tar.gz Result: your RediSearch-1.2.2/src/doc_table.c:416:7: warning: If memory allocation fails, then there is a possible null pointer dereference: dmd [nullPointerOutOfMemory] RediSearch-1.2.2/src/doc_table.c:399:40: note: Assuming allocation function fails RediSearch-1.2.2/src/doc_table.c:399:40: note: Assignment 'dmd=calloc(1,sizeof(struct RSDocumentMetadata))', assigned value is 0 RediSearch-1.2.2/src/doc_table.c:415:16: note: Assuming condition is true RediSearch-1.2.2/src/doc_table.c:416:7: note: Null pointer dereference Explanation: The warning itself is unchanged: `dmd` comes from an unchecked `calloc`, so dereferencing it at line 416 when allocation fails is a real (OOM) null dereference. Only the 'Assuming condition is true' note changed. Main pointed to line 401 (`encver < INDEX_MIN_BINKEYS_VERSION`), which has nothing to do with reaching line 416. The PR points to line 415 (`encver >= INDEX_MIN_DOCLEN_VERSION`), the condition that actually guards the dereference. The path explanation is now more accurate. ---- 41 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/redisearch/redisearch_1.2.2.orig.tar.gz Result: your RediSearch-1.2.2/src/doc_table.c:423:5: warning: If memory allocation fails, then there is a possible null pointer dereference: dmd [nullPointerOutOfMemory] RediSearch-1.2.2/src/doc_table.c:399:40: note: Assuming allocation function fails RediSearch-1.2.2/src/doc_table.c:399:40: note: Assignment 'dmd=calloc(1,sizeof(struct RSDocumentMetadata))', assigned value is 0 RediSearch-1.2.2/src/doc_table.c:415:16: note: Assuming condition is true RediSearch-1.2.2/src/doc_table.c:423:5: note: Null pointer dereference Explanation: Both versions report the same true positive: `dmd` comes from an unchecked `rm_calloc` and is written at line 423. Only the intermediate 'Assuming condition is true' note changed, from line 401 to line 415. The dereference at line 423 is unconditional, so either condition note is equally irrelevant. The warning's location, text and validity are unchanged, so this does not matter to users. ---- 42 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/rpp/rpp_7.1.1+dfsg.orig.tar.xz Result: main ROCm-rpp-3bda049/src/modules/batch_pd/hip/kernel/local_binary_pattern.cpp:222:59: style: Condition '(id_y-1)>=0' is always true [knownConditionTrueFalse] ROCm-rpp-3bda049/src/modules/batch_pd/hip/kernel/local_binary_pattern.cpp:212:50: note: Assuming that condition '(id_y-1)>=0' is not redundant ROCm-rpp-3bda049/src/modules/batch_pd/hip/kernel/local_binary_pattern.cpp:222:59: note: Condition '(id_y-1)>=0' is always true Explanation: Line 204 guards the whole block with `id_y > 0`, and `id_y` is a local int that is never modified afterwards. So `(id_y - 1) >= 0` at line 222 really is always true, and the removed knownConditionTrueFalse warning was a true positive. Main may have reached it by wrongly treating `id_y > 0` as `id_y == 1`, which the PR fixes. But the PR's new range tracking should still prove `id_y - 1 >= 0` from `id_y > 0`, and it no longer does. Losing a correct warning is a regression. ---- 43 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/scilab/scilab_2024.1.0+dfsg1.orig.tar.xz Result: main scilab-2024.1.0/scilab/modules/differential_equations/src/patched_sundials/src/nvector/serial/nvector_serial.c:873:27: warning: If memory allocation fails, then there is a possible null pointer dereference: X [nullPointerOutOfMemory] scilab-2024.1.0/scilab/modules/differential_equations/src/patched_sundials/src/nvector/serial/nvector_serial.c:1398:27: note: Assuming allocation function fails scilab-2024.1.0/scilab/modules/differential_equations/src/patched_sundials/src/nvector/serial/nvector_serial.c:1398:9: note: Assignment 'Y=(N_Vector*)malloc(nsum*sizeof(N_Vector))', assigned value is 0 scilab-2024.1.0/scilab/modules/differential_equations/src/patched_sundials/src/nvector/serial/nvector_serial.c:1404:51: note: Calling function 'N_VLinearCombination_Serial', 3rd argument 'Y' value is 0 scilab-2024.1.0/scilab/modules/differential_equations/src/patched_sundials/src/nvector/serial/nvector_serial.c:869:12: note: Assuming condition is false scilab-2024.1.0/scilab/modules/differential_equations/src/patched_sundials/src/nvector/serial/nvector_serial.c:873:27: note: Null pointer dereference Explanation: The caller at line 1398 (the nvec == 1 branch of the vector-array linear combination) only reaches the malloc and the call `N_VLinearCombination_Serial(nsum, c, Y, Z[0])` after excluding `nsum < 1`, `nsum == 1` and `nsum == 2` (assumed from the standard sundials code; that code is not shown). So `nsum > 2` there. In the callee `nvec == nsum >= 3`, so the `nvec == 1` branch at line 873 cannot run with `X == NULL`. The warning's path through line 873 is infeasible. The PR now keeps several constraints together (`>= 1`, `!= 1`, `!= 2`, merged into `> 2`), which removes this false positive. The OOM null dereference does exist elsewhere (`Y[i] = ...` in the caller), but this particular report was wrong. ---- 44 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/scilab/scilab_2024.1.0+dfsg1.orig.tar.xz Result: your scilab-2024.1.0/scilab/modules/scicos_blocks/src/c/readau.c:122:21: warning: Either the condition 'mu>127' is redundant or the array 'ETAB[8]' is accessed at index 8, which is out of bounds. [arrayIndexOutOfBoundsCond] scilab-2024.1.0/scilab/modules/scicos_blocks/src/c/readau.c:100:20: note: Assuming that condition 'mu>127' is not redundant scilab-2024.1.0/scilab/modules/scicos_blocks/src/c/readau.c:113:18: note: quot is assigned 'mu/16' here. scilab-2024.1.0/scilab/modules/scicos_blocks/src/c/readau.c:115:32: note: Assignment 'e=quot-8*sig+1', assigned value is 9 scilab-2024.1.0/scilab/modules/scicos_blocks/src/c/readau.c:122:21: note: Array index out of bounds Explanation: When mu > 127, sig is set to 1, so e = mu/16 - 7 and ETAB[e-1] = ETAB[mu/16 - 8]. For mu in 128..255 that is index 0..7, which is in bounds. Reaching index 8 needs mu >= 256, which means record[i] < 0. The input is decoded mu-law byte data, so that does not happen. The reported 'e ... assigned value is 9' looks like mu = 128 (from the condition's bound) combined with sig = 0, an infeasible mix like the two removed false positives. The PR swaps those two false positives for this new arrayIndexOutOfBoundsCond warning, which is also a false positive; this added line itself is a regression. ---- 45 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/scilab/scilab_2024.1.0+dfsg1.orig.tar.xz Result: your scilab-2024.1.0/scilab/modules/string/src/c/strsplit.c:104:16: warning: Either the condition 'splitted[sizeIndices]==NULL' is redundant or there is possible null pointer dereference: wcStrDest. [nullPointerRedundantCheck] scilab-2024.1.0/scilab/modules/string/src/c/strsplit.c:96:35: note: Assuming that condition 'splitted[sizeIndices]==NULL' is not redundant scilab-2024.1.0/scilab/modules/string/src/c/strsplit.c:94:9: note: Assignment from 'wcStrDest=splitted[sizeIndices]' scilab-2024.1.0/scilab/modules/string/src/c/strsplit.c:96:35: note: Assuming condition is false scilab-2024.1.0/scilab/modules/string/src/c/strsplit.c:104:16: note: Null pointer dereference Explanation: wcStrDest is assigned splitted[sizeIndices] on line 94. Line 96 checks splitted[sizeIndices] for NULL and returns when it is, so on line 104 splitted[sizeIndices], and therefore wcStrDest, is non-NULL. The new nullPointerRedundantCheck at line 104 is a false positive. The PR's program-memory changes apparently lost the link between wcStrDest and splitted[sizeIndices] after the NULL check, so a new false positive was added. ---- 46 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/scilab/scilab_2024.1.0+dfsg1.orig.tar.xz Result: your scilab-2024.1.0/scilab/modules/string/src/c/strsplit.c:87:13: warning: Either the condition 'splitted[i]==NULL' is redundant or there is possible null pointer dereference: wcStrDest. [nullPointerRedundantCheck] scilab-2024.1.0/scilab/modules/string/src/c/strsplit.c:79:29: note: Assuming that condition 'splitted[i]==NULL' is not redundant scilab-2024.1.0/scilab/modules/string/src/c/strsplit.c:77:13: note: Assignment from 'wcStrDest=splitted[i]' scilab-2024.1.0/scilab/modules/string/src/c/strsplit.c:79:29: note: Assuming condition is false scilab-2024.1.0/scilab/modules/string/src/c/strsplit.c:87:13: note: Null pointer dereference Explanation: wcStrDest is set to splitted[i] at line 77. If splitted[i] is NULL, the check at line 79 returns, so wcStrDest cannot be null at line 87. The new nullPointerRedundantCheck is a false positive. Cppcheck fails to connect the null check on splitted[i] with the alias wcStrDest after the PR's program memory changes. ---- 47 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/seqtk/seqtk_1.4.orig.tar.gz Result: main seqtk-1.4/seqtk.c:149:11: style: Condition 'end<0' is always true [knownConditionTrueFalse] seqtk-1.4/seqtk.c:126:24: note: Assignment 'end=-1', assigned value is -1 seqtk-1.4/seqtk.c:149:11: note: Condition 'end<0' is always true Explanation: Line 149 is in a loop. 'end' starts at -1 but can be set on line 141 when the third column holds a number. So 'end<0' is not always true, and the old warning was a false positive. Removing it is an improvement. ---- 48 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/seqtk/seqtk_1.4.orig.tar.gz Result: main seqtk-1.4/seqtk.c:150:11: style: Condition 'beg<0' is always true [knownConditionTrueFalse] seqtk-1.4/seqtk.c:126:14: note: Assignment 'beg=-1', assigned value is -1 seqtk-1.4/seqtk.c:150:11: note: Condition 'beg<0' is always true Explanation: beg starts at -1, but line 138 may set it with atoi(str->s) when dret != '\n' and a digit follows. Line 149 may also change it with 'beg = beg - 1'. So 'beg<0' at line 150 is not always true. The old warning was a false positive: main wrongly treated beg as -1 on every path. The PR's handling of ranges from conditions removes it, which is correct. ---- 49 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/t/tulip/tulip_6.0.1+dfsg.orig.tar.xz Result: main tulip-6.0.1/library/tulip-ogl/src/GlPolyQuad.cpp:192:68: error: Out of bounds access in expression 'texCoordsArray[0]' because 'texCoordsArray' is empty. [containerOutOfBounds] Explanation: In GlPolyQuad::draw(), texCoordsArray is filled by push_back calls inside the loop over polyQuadEdges, both in the subdivision branch and in the nbSubdivisionsPerSegment == 1 branch. In the tulip source, which is not shown in the excerpt, the function starts with an assert that polyQuadEdges.size() > 2, so the loop runs at least once. texCoordsArray is therefore not empty at line 192, and the warning was a false positive. The PR now records conditions such as 'size > N' as ranges instead of single values, so Cppcheck no longer wrongly concludes that the container is empty. The sibling warnings for colorsArray and quadIndices disappeared the same way. ---- 50 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/t/tulip/tulip_6.0.1+dfsg.orig.tar.xz Result: main tulip-6.0.1/library/tulip-ogl/src/GlPolyQuad.cpp:193:62: error: Out of bounds access in expression 'colorsArray[0]' because 'colorsArray' is empty. [containerOutOfBounds] Explanation: Before line 193, the function fills colorsArray inside a loop over the polyQuadEdges pairs, and through emplace_back/push_back in the branch at lines 171-172. The vector is empty only if that loop never runs. The source likely has an assert or condition such as `polyQuadEdges.size() > 2` (not shown in the excerpt). The old program memory turned a range condition like that into a single value (size == 3). With that value, (3/2)-1 = 0, so the loop looked as if it never ran and colorsArray looked always empty. The PR stores such conditions as ranges, so the loop is no longer wrongly treated as dead. The sibling warnings for texCoordsArray and quadIndices disappeared the same way. This removes a false positive.