AI review of 2026-11-06_13-19-25-811a54c90d71-results.txt PR: #8996 https://github.com/cppcheck-opensource/cppcheck/pull/8996 Tested: 811a54c90d710e1e6afdd83ec136640218b3e273 Merge base: a7b9e1cc22dd4d6f345dfec61d6172bb3253bad2 Reviewed: 2026-11-07 23:38:02 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 109 in the report (random sample) Verdicts: 29 acceptable regression, 11 improvement, 4 neutral, 5 regression, 1 unclear Tokens: 88262 input, 89840 cache read, 22460 cache write, 38941 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/7/7kaa/7kaa_2.15.7+ds.orig.tar.xz Result: your 7kaa-2.15.7/src/OAI_SEEK.cpp:505:2: warning: Uninitialized variable: refX1 [uninitvar] 7kaa-2.15.7/src/OAI_SEEK.cpp:462:21: note: Assuming condition is false 7kaa-2.15.7/src/OAI_SEEK.cpp:482:26: note: Assuming condition is false 7kaa-2.15.7/src/OAI_SEEK.cpp:505:2: note: Uninitialized variable: refX1 Explanation: refX1 is only assigned in the firm and town branches. The else branch only calls err_here(), and the code then does `refX1 -= ...`, which reads refX1. The PR now treats compound assignment as a read of the old value, which is correct. Cppcheck follows the path where neither condition holds. err_here() is most likely compiled out in non-debug builds (from memory of 7kaa's headers, not shown here), and even in debug builds it is not known to be noreturn. On that path refX1 really is read uninitialized. Previously the `-=` hid this. The path only happens if the error handler fails to stop execution, but the warning is technically correct and matches what the PR intends to detect. ---- 2 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/7/7kaa/7kaa_2.15.7+ds.orig.tar.xz Result: your 7kaa-2.15.7/src/OAI_SEEK.cpp:506:2: warning: Uninitialized variable: refY1 [uninitvar] 7kaa-2.15.7/src/OAI_SEEK.cpp:462:21: note: Assuming condition is false 7kaa-2.15.7/src/OAI_SEEK.cpp:482:26: note: Assuming condition is false 7kaa-2.15.7/src/OAI_SEEK.cpp:506:2: note: Uninitialized variable: refY1 Explanation: `refY1` is only assigned in the `is_firm()` and `is_town()` branches. The final `else` branch only calls `err_here()`, which in 7kaa is typically an error-reporting macro (or empty in non-DEBUG builds) and is not known to be noreturn. On that path, `refY1 -= firmLocHeight/2` reads an uninitialized value. Before the PR, Cppcheck did not treat a compound assignment as a read of the old value; now it does. The new warning matches the actual data flow on a path the code itself anticipates. It is not certain that `err_here()` never returns, so the warning is plausibly a true positive rather than a false one. ---- 3 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/a/apngopt/apngopt_1.4.orig.tar.xz Result: main apngopt.cpp:800:19: style: Variable 'prev' can be declared as pointer to const [constVariablePointer] Explanation: In `process_rect`, `prev` starts as NULL. Judging from the visible part and the usual structure of this filter code, it is later set to the previous row and only read (e.g. `row[i] - prev[i]`). That makes the `constVariablePointer` suggestion a true positive. The PR makes compound assignments (such as `row += stride` or `from += ...`) invalidate tracked values, which apparently makes Cppcheck lose the information it needed to suggest const here. The `window` warning in zlib/inffast.c disappeared the same way. Losing this correct style warning is a new false negative, not a removed false positive. Confidence is medium because the loop body where `prev` is used and assigned is not shown. ---- 4 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/a/apngopt/apngopt_1.4.orig.tar.xz Result: main zlib/inffast.c:83:24: style: Variable 'window' can be declared as pointer to const [constVariablePointer] Explanation: In inflate_fast, `window` is never written through directly. It is only used as `from = window - OFF` / `from = window + ...`, and the bytes are then read via `PUP(from)`. Here `from` is declared as a non-const `unsigned char *`. Making `window` const would also require making `from` const. That is technically possible, since `from` is only read, so the old warning is borderline: true-ish, but it needs a cascading change. The PR only changes how compound assignments (`from += wsize - op`, `out += ...`) invalidate valueflow values. It is not clear from the shown code how that changes the constVariablePointer result for `window`. So it cannot be determined whether this is a correctly removed false positive or a lost true positive. ---- 5 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/berkeley-abc/berkeley-abc_1.01+20221019git70cb339+dfsg.orig.tar.xz Result: main berkeley-abc-0.0~git20221019.70cb339/src/misc/zlib/inffast.c:88:24: style: Variable 'window' can be declared as pointer to const [constVariablePointer] Explanation: In zlib's inflate_fast, `window` is copied into the non-const pointer `from` (`from = window - OFF;`, then `from += ...`). Declaring `window` as pointer to const would discard the qualifier on that assignment, which is a diagnostic in C and an error in C++. So the constVariablePointer warning was a false positive. The PR changes how compound assignments are handled in value flow, which apparently makes Cppcheck track this alias better, and the removal looks correct. ---- 6 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-m68hc1x/binutils-m68hc1x_2.35.1.orig.tar.xz Result: main binutils-2.35.1/bfd/elf32-nds32.c:5877:18: style: Variable 'srelplt' can be declared as pointer to const [constVariablePointer] Explanation: `srelplt` is only read: `loc = srelplt->contents` and a comparison against `srelplt->contents + srelplt->size`. `contents` is a plain `bfd_byte *` member. With `const asection *srelplt` it becomes `bfd_byte * const`, so assigning it to `loc` and writing through `loc` still compiles. The `constVariablePointer` suggestion was therefore valid. The PR now marks compound assignments (`loc += ...`) as Read|Invalid in the value-flow analyzer, and this appears to have suppressed the warning as a side effect. That is a lost true positive, i.e. a new false negative for a style check. ---- 7 / 50 ---- Verdict: ACCEPTABLE REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/c/ccextractor/ccextractor_0.88+ds1.orig.tar.xz Result: main ccextractor-0.88/src/gpacmp4/color.c:1319:24: style: Variable 'dst_bits_prev' can be declared as pointer to const [constVariablePointer] Explanation: In gf_stretch_bits, `dst_bits_prev` looks like a row pointer that is only read from (e.g. as a memcpy source) and reassigned. That would make the constVariablePointer suggestion a true positive. The PR only changes valueflow handling of compound assignments, which should not make the pointee mutable. So the removal most likely comes from changed value tracking, not from a real write through the pointer. The function body that uses the pointer is not shown, so this cannot be confirmed. ---- 8 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/e/erlang/erlang_29.1.2+dfsg.orig.tar.xz Result: main otp-OTP-29.1.2/erts/emulator/sys/unix/erl_child_setup.c:194:17: style: Variable 'cwd' can be declared as pointer to const [constVariablePointer] Explanation: In `start_new_child`, `cwd` (and `wd`) just point into the received buffer (`cwd = buff;`) and are only read afterwards, for example as a `chdir` argument or a `'\0'` check. So suggesting `const char *cwd` looks like a valid style hint, i.e. a true positive. The PR makes compound assignments such as `buff += ...` invalidate tracked values. As a side effect this suppresses the constVariablePointer warnings for both `cwd` and `wd` on this line. Losing a probably-correct style warning is a new false negative. The later uses of `cwd` are not shown, so confidence is only medium. ---- 9 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/e/erlang/erlang_29.1.2+dfsg.orig.tar.xz Result: main otp-OTP-29.1.2/erts/emulator/sys/unix/erl_child_setup.c:194:23: style: Variable 'wd' can be declared as pointer to const [constVariablePointer] Explanation: `wd` is set to point into `buff` (the serialized child data). As far as the visible pattern and typical OTP code show, it is only read afterwards, e.g. passed to chdir and printed. So the constVariablePointer style warning was most likely a true positive. The PR now marks compound assignments such as `buff += strlen(buff) + 1` as invalidating values. That changes how the aliasing between `wd`/`cwd` and `buff` is tracked, which suppresses the warning. Losing it is a new false negative, not a fixed false positive. Confidence is medium because the later uses of `wd` are not shown. ---- 10 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/e/erlang/erlang_29.1.2+dfsg.orig.tar.xz Result: your otp-OTP-29.1.2/erts/emulator/beam/jit/beam_jit_metadata.cpp:190:13: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] otp-OTP-29.1.2/erts/emulator/beam/jit/beam_jit_metadata.cpp:171:35: note: Assuming allocation function fails otp-OTP-29.1.2/erts/emulator/beam/jit/beam_jit_metadata.cpp:171:21: note: Assignment 'symfile=(char*)malloc(symfile_size)', assigned value is 0 otp-OTP-29.1.2/erts/emulator/beam/jit/beam_jit_metadata.cpp:190:13: note: Null pointer addition Explanation: `symfile` comes from `malloc` at line 171 and is never checked for NULL. It is not reassigned before line 190, where `symfile += ...` does arithmetic on it. If the allocation fails, that is pointer arithmetic on NULL, which is undefined behaviour. The PR deliberately makes compound assignments like `+=` count as a read of the old value, so Cppcheck now reports this case; the updated test expects exactly this. Line 179 would likely crash first through the `debug_info` alias, but the unchecked malloc is a real bug and the new warning describes it correctly. This is a true positive. ---- 11 / 50 ---- Verdict: ACCEPTABLE REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/e/euslisp/euslisp_9.32+dfsg.orig.tar.xz Result: main euslisp-9.32+dfsg/lisp/tool/eustags.c:1607:18: style: Variable 'pend' can be declared as pointer to const [constVariablePointer] Explanation: In `readline`, `pend` is only ever assigned (`p + size`, `buffer + size`) and compared with `p`. It is never written through, so `const char *pend` would compile fine and the constVariablePointer warning looks like a true positive. The PR makes compound assignments such as `p += buffer - linebuffer->buffer` invalidate tracked values, which apparently stops Cppcheck from reaching this style finding. That is a new false negative, not a removed false positive. Confidence is low because the reported location (line 1607, column 18) does not match the shown declaration of `pend` at line 1617. ---- 12 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/fitscut/fitscut_1.4.4.orig.tar.gz Result: main fitscut-1.4.4/image_scale.c:128:16: style: Variable 'src' can be declared as pointer to const [constVariablePointer] Explanation: In the code shown, `src` is only used to read: it is assigned from `linep`, read through `*src`, and incremented with `src++`. Incrementing changes the pointer itself, not the pointee, so declaring it `const float *src` would be valid. The removed constVariablePointer warning therefore looks like a true positive. Its disappearance is probably a side effect of the PR's new handling of compound assignments in valueflow, such as a likely `linep += ncols` after line 168. That would make this a new false negative. Confidence is medium because the code after line 168 is not shown. ---- 13 / 50 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/g/glpk/glpk_5.0.orig.tar.gz Result: main glpk-5.0/src/zlib/inffast.c:83:24: style: Variable 'window' can be declared as pointer to const [constVariablePointer] Explanation: `window` is never written through, but its value is copied into the non-const pointer `from` (`from = window - OFF;`). `from` is then modified with `from += ...` and dereferenced. If only `window` were made `const unsigned char *`, that assignment would drop the const qualifier: a diagnostic in C and an error in C++. So the suggestion to make `window` alone pointer-to-const is not directly applicable, and the old warning was likely a false positive. The PR makes compound assignments such as `from +=` invalidate the tracked value. This plausibly changes how the alias `from` is analysed and so removes the warning. Removing it looks like an improvement, but the exact mechanism is not certain. ---- 14 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gngb/gngb_20060309.orig.tar.gz Result: main gngb-20060309/src/video_std.c:648:57: style: Parameter 'sp' can be declared as pointer to const [constParameterPointer] Explanation: In draw_spr_col_std, 'sp' is only read (sp->page, sp->no_tile, sp->yflip, sp->yoff, sp->x, sp->pal_col, and so on). Nothing writes through it in the code shown, so the constParameterPointer suggestion looks like a true positive. The likely cause of its disappearance is the PR's new compound-assignment handling (the `tp += ...` lines), which makes valueflow mark the value Invalid and indirectly suppresses this style warning. Losing a correct warning is a new false negative, not a fixed false positive. Confidence is medium because GET_GB_PIXEL and how the function is used (for example through a function pointer) are not shown. ---- 15 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/i/indent/indent_2.2.13.orig.tar.xz Result: main indent-2.2.13/regression/standard/indent.pro.c:5:3: error: Uninitialized variable: i [legacyUninitvar] Explanation: In `int i, j; i <<= 1;` the variable `i` is read before it is ever initialized, so the warning is a true positive. The PR does not drop it. The same warning on the same line is now reported by the valueflow-based check under the id `uninitvar` instead of `legacyUninitvar`. This is only a change of message id, and the user gets the same diagnostic. ---- 16 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/indent/indent_2.2.13.orig.tar.xz Result: main indent-2.2.13/src/handletoken.c:903:23: style: Variable 'p2' can be declared as pointer to const [constVariablePointer] Explanation: `p2` is only read: it is compared with `e_code`, incremented, and dereferenced as the source in `*p1++ = *p2++`. It is never written through, so `const char *p2` would be valid and the constVariablePointer warning was a true positive. The PR removes it without an obvious reason, probably as a side effect of the changed valueflow handling of compound assignments such as `e_code -= *dec_ind`. That is a new false negative for a style warning. ---- 17 / 50 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/i/indent/indent_2.2.13.orig.tar.xz Result: your indent-2.2.13/regression/standard/indent.pro.c:6:3: error: Uninitialized variable: j [uninitvar] Explanation: `j` is declared without an initializer, and `j >>= 1` reads it, so the warning is a true positive. Both main and the PR report this same location with the same message. The only difference is that the warning ID changed from legacyUninitvar to uninitvar, because the valueflow-based checker now handles compound assignment. The user sees essentially the same warning. ---- 18 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/insighttoolkit4/insighttoolkit4_4.13.3withdata-dfsg2.orig.tar.gz Result: main insighttoolkit4-4.13.3withdata-dfsg2/Modules/ThirdParty/OpenJPEG/src/openjpeg/invert.c:207:17: style: Variable 'lTmpMatrix' can be declared as pointer to const [constVariablePointer] Explanation: In opj_lupSolve, lTmpMatrix is only used to read matrix elements: `sum += (*(lTmpMatrix++)) * ...` and `u = *(lTmpMatrix++)`. In the visible code, and in the upstream OpenJPEG function, nothing is ever written through it. It is assigned from the non-const lLineMatrix, which is fine for a pointer to const. So the constVariablePointer suggestion was correct. The PR's new compound-assignment handling (e.g. `lLineMatrix += n`, `sum +=`) removed this true positive, which makes it a new false negative. ---- 19 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/l/lcrq/lcrq_0.4.1.orig.tar.gz Result: your lcrq/examples/speedtest.c:53:7: error:inconclusive: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] lcrq/examples/speedtest.c:46:14: note: Assuming allocation function fails lcrq/examples/speedtest.c:46:14: note: Assignment 'enc=malloc(nesi*rq_T(rq))', assigned value is 0 lcrq/examples/speedtest.c:49:8: note: Assignment 'sym=enc', assigned value is 0 lcrq/examples/speedtest.c:53:7: note: Null pointer addition Explanation: `enc = malloc(...)` is never checked for NULL. `sym = enc`, and inside the loop `sym += rq_T(rq)` performs pointer arithmetic on `sym`. If the allocation fails, that is pointer arithmetic on a NULL pointer, which is undefined behaviour. `rq_symbol` gets `sym` by value, so it cannot change it. Before the PR, the compound assignment `+=` was handled like a plain write and the null value was dropped. Now the NULL value reaches the `+=`, so this inconclusive out-of-memory warning is a valid new true positive. This matches the updated test in testnullpointer.cpp. ---- 20 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/l/lsof/lsof_4.99.4+dfsg.orig.tar.xz Result: main lsof-4.99.4/lib/misc.c:1574:16: style: Variable 'cp1' can be declared as pointer to const [constVariablePointer] Explanation: In `x2dev()`, `cp1` is set from `s`, compared to `s`, dereferenced only for reading (`*cp1 != 'f'`) and incremented. It is never written through, so declaring it `const char *cp1` is valid, and the constVariablePointer warning was a true positive. The PR now marks compound assignments such as `s += ...` as invalidating tracked values. That apparently changed the valueflow information for `cp1`/`s`, and the warning is no longer reported. Losing a correct style warning is a new false negative. ---- 21 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/libb/libbpf/libbpf_1.7.0.orig.tar.gz Result: your libbpf-1.7.0/src/linker.c:3044:6: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] libbpf-1.7.0/src/linker.c:3035:21: note: Assuming allocation function fails libbpf-1.7.0/src/linker.c:3035:13: note: Assignment 'cur=data=calloc(1,total_sz)', assigned value is 0 libbpf-1.7.0/src/linker.c:3036:6: note: Assuming condition is false libbpf-1.7.0/src/linker.c:3044:6: note: Null pointer addition Explanation: The new nullPointerArithmeticOutOfMemory warning is a false positive. In `cur = data = calloc(...)`, the null check at line 3036 is on `data`, and the function returns -ENOMEM if it is NULL. So at line 3044 `cur` (equal to `data`) cannot be NULL. Cppcheck does not connect `cur` with the `!data` check. The PR now treats the compound assignment `cur +=` as a Read with the old value still flowing to it, which exposes the stale 'cur is 0' value. The 'Assuming condition is false' note admits that the check was considered, yet the warning is still reported. ---- 22 / 50 ---- Verdict: ACCEPTABLE REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/libh/libhugetlbfs/libhugetlbfs_2.24.orig.tar.gz Result: main libhugetlbfs-2.24/tests/stack_grow_into_huge.c:82:8: style: Variable 'stack_address' can be declared as pointer to const [constVariablePointer] Explanation: `stack_address` is assigned from `alloca(0)`. It is then only read: once in pointer arithmetic, and once passed to `PALIGN`, which casts it to `unsigned long`. Nothing is ever written through it, so declaring it `const void *` looks valid, and the removed warning looks like a true positive. The PR changes how compound assignments are handled in valueflow. This most likely affected the line `mmap_address -= hpage_size`, and indirectly suppressed this style warning. That would be a new false negative. It is unclear exactly how the change reached this warning, and the rest of the function is not shown, so confidence is low. ---- 23 / 50 ---- Verdict: ACCEPTABLE REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/libi/libisoburn/libisoburn_1.5.8.pl02.orig.tar.gz Result: main libisoburn-1.5.8/xorriso/misc_funct.c:1027:30: style: Parameter 'start' can be declared as pointer to const [constParameterPointer] Explanation: In the visible code, `start` is only read: it is passed to `strlen`, `strcmp` and `strstr`, and `start[0]` is compared. It is a marker string, and nothing visible writes through it, so the `constParameterPointer` suggestion looks like a true positive. The PR only changes how valueflow treats compound assignments (`+=`, `<<=`, ...). Code such as `wpt += spt - rpt` probably now invalidates values, which likely made Cppcheck stop proving that `start` is never written through. That makes this a lost true positive (a new false negative), not a removed false positive. The rest of the function is not shown, so a write through `start` further down cannot be fully ruled out. ---- 24 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsdl2-gfx/libsdl2-gfx_1.0.4+dfsg.orig.tar.gz Result: main SDL2_gfx-1.0.4/SDL2_rotozoom.c:280:20: style: Variable 'c01' can be declared as pointer to const [constVariablePointer] Explanation: In _zoomSurfaceRGBA, c01 is set from sp, moved with ++/-- for the horizontal step, and then only read (c01->r, c01->g, …) to compute the interpolated color. Nothing is ever written through it, so it could be declared `const tColorRGBA *`, and the constVariablePointer warning was a true positive. The PR's compound-assignment handling in the valueflow analyzer apparently changed the analysis so that this warning (and the one for c00) disappears. That is a new false negative for a style check, which makes it an acceptable regression. ---- 25 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libslirp/libslirp_4.9.5.orig.tar.bz2 Result: main libslirp-v4.9.5/src/sbuf.c:153:26: style: Parameter 'sb' can be declared as pointer to const [constParameterPointer] Explanation: `sbcopy` only reads through `sb`: it reads `sb_data`, `sb_datalen`, `sb_wptr`, `sb_rptr` and `sb_cc`, and copies from the buffer with `memcpy`. With `const struct sbuf *sb`, `sb->sb_rptr` has type `char * const`, so `from = sb->sb_rptr + off` still compiles. `from -= sb->sb_datalen` changes only the local `from`. So the constParameterPointer warning was a true positive. The PR now treats compound assignments as Read|Invalid, which seems to have side-effected the const analysis. The result is a lost true positive, i.e. a new false negative. ---- 26 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libx/libxaw/libxaw_1.0.16.orig.tar.gz Result: main libXaw-1.0.16/src/MultiSrc.c:546:17: style: Variable 'piece' can be declared as pointer to const [constVariablePointer] Explanation: In Scan(), 'piece' is assigned from FindPiece() and then only read: piece->used and piece->text are read, and the pointer itself is advanced to prev/next. Nothing visible writes through 'piece'. Copying piece->text into a non-const 'wchar_t *ptr' is still allowed if piece points to const, because the member pointer keeps its non-const pointee type. So 'const MultiPiece *piece' looks valid and the warning looks like a true positive. The PR now marks compound assignments (e.g. on ptr, which aliases piece->text) as invalidating values. That likely made the const analysis more conservative, so the true positive was dropped. The full function body is not shown, hence medium confidence. ---- 27 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libx/libxaw/libxaw_1.0.16.orig.tar.gz Result: main libXaw-1.0.16/src/MultiSrc.c:695:17: style: Variable 'piece' can be declared as pointer to const [constVariablePointer] Explanation: In Search(), `piece` gets the result of FindPiece() and is then only read: `piece->text`, `piece->used`, `piece->prev` and `piece->next`. It is also reassigned, which is fine for a pointer to const. Reading `piece->text` from a `const MultiPiece*` still yields a `wchar_t*` that can be stored in `ptr`. So declaring it `const MultiPiece *piece` looks valid, and the constVariablePointer warning was most likely a true positive. The PR treats compound assignments such as `ptr += inc` and `ptr -= inc*count` as Read|Invalid. This apparently makes the analysis more conservative here and suppresses the style warning. The result is a lost true positive (a new false negative), not a removed false positive. ---- 28 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/magic/magic_8.3.105+ds.1.orig.tar.xz Result: main magic-8.3.105/plot/plotRutils.c:427:13: style: Parameter 'raster' can be declared as pointer to const [constParameterPointer] Explanation: In the visible code `raster` is only read: `raster->ras_bits`, `ras_height` and `ras_intsPerLine`. The function writes through `left`/`cur`, which point into the `int*` buffer `ras_bits`. That data stays writable even if the parameter is `const Raster *`, because only the pointer member itself becomes const. So the removed constParameterPointer warning looks like a valid style finding. The PR's new handling of compound assignments (`left += ...`, `cur += 1`, `*left |= ...`) probably makes Cppcheck treat the derived pointer as a change to `raster`, which suppresses the warning. That makes this a new false negative rather than a fixed false positive. The rest of the function is not shown, so confidence is medium. ---- 29 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/mysqmail/mysqmail_0.4.9.orig.tar.gz Result: your mysqmail-0.4.9/mysqmail-postfix-logger.c:161:8: warning: Either the condition 'cur_p!=NULL' is redundant or there is pointer arithmetic with NULL pointer. [nullPointerArithmeticRedundantCheck] mysqmail-0.4.9/mysqmail-postfix-logger.c:155:29: note: Assuming that condition 'cur_p!=NULL' is not redundant mysqmail-0.4.9/mysqmail-postfix-logger.c:161:8: note: Null pointer addition Explanation: The `while` loop can end because `strtok` returned NULL (a line with fewer than 6 words), so `cur_p` can be NULL at line 161. `cur_p += strlen(cur_p) + 1` then does pointer arithmetic on NULL, and `strlen(NULL)` would also crash. The `cur_p != NULL` check in the loop shows that NULL is expected here. The PR now treats the compound assignment `+=` as a read of `cur_p`, so this real bug is reported. The new warning is a true positive. ---- 30 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/numdiff/numdiff_5.9.0.orig.tar.gz Result: your numdiff-5.9.0/analyze.c:428:38: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] numdiff-5.9.0/analyze.c:424:15: note: Assuming allocation function fails numdiff-5.9.0/analyze.c:424:15: note: Assignment 'p=xmalloc((filevec[0].buffered_lines+filevec[1].buffered_lines)*(2*sizeof(*p)))', assigned value is 0 numdiff-5.9.0/analyze.c:428:38: note: Null pointer addition Explanation: The PR now treats a compound assignment such as `p += n` as a read of the old value, so the 'NULL after failed allocation' value now reaches the `p += filevec[f].buffered_lines` in the loop. The allocator here is `xmalloc`, the GNU-style wrapper used by numdiff (inherited from diffutils). It exits on out-of-memory and never returns NULL. Assuming it 'fails' with a NULL result is therefore wrong, and the new nullPointerArithmeticOutOfMemory warning is a false positive. ---- 31 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/numdiff/numdiff_5.9.0.orig.tar.gz Result: your numdiff-5.9.0/analyze.c:831:13: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] numdiff-5.9.0/analyze.c:829:23: note: Assuming allocation function fails numdiff-5.9.0/analyze.c:829:23: note: Assignment 'fdiag=xmalloc(diags*(2*sizeof(*fdiag)))', assigned value is 0 numdiff-5.9.0/analyze.c:831:13: note: Null pointer addition Explanation: The warning points at `fdiag += filevec[1].nondiscarded_lines + 1;`, right after `fdiag = xmalloc(...)`. The PR makes the null value from an assumed allocation failure visible at compound assignments, so `+=` is now flagged. But `xmalloc` in GNU-diff-derived code like numdiff's analyze.c conventionally reports the error and exits on failure; it never returns NULL. I did not see numdiff's `xmalloc` itself, so this rests on that convention. If it holds, the 'if memory allocation fails' path cannot happen, and this is a newly added false positive. It duplicates any similar report on `bdiag = fdiag + diags`, adding noise rather than a real bug. ---- 32 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pango1.0/pango1.0_1.58.2.orig.tar.xz Result: main pango-1.58.2/pango/pangoft2-render.c:317:12: style: Variable 's' can be declared as pointer to const [constVariablePointer] Explanation: In both loops `s` is only used to read pixels (`*s` in the switch, `(*s) & ...`) and is itself incremented (`s++`). The pointed-to data is never written, so `const guchar *s = src;` would compile and the constVariablePointer warning was a true positive. The PR changes how compound assignments are treated in valueflow, which here affects `src += x_start` and `src += pitch`. That apparently disturbs the analysis enough to drop both warnings. Losing a correct style warning is a new false negative. ---- 33 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/pango1.0/pango1.0_1.58.2.orig.tar.xz Result: main pango-1.58.2/pango/pangoft2-render.c:347:12: style: Variable 's' can be declared as pointer to const [constVariablePointer] Explanation: In the mono branch, `s` is initialised from `src`. It is then only dereferenced for reading (`(*s) & ...`) and incremented (`s++`). Nothing is ever written through `s`, so declaring it `const guchar *s` is valid. The constVariablePointer warning was a true positive. The same holds for the matching line 317. The PR changes how compound assignments such as `src += ...` are treated in valueflow, which apparently suppresses this warning as a side effect. Losing a correct style warning is a new false negative. ---- 34 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/phoc/phoc_0.58.0.orig.tar.xz Result: your phoc-0.58.0/subprojects/wlroots-0.20.x/examples/rotation.c:102:18: error: Uninitialized variable: sample_output->x_vel [uninitvar] Explanation: `wl_list_for_each` assigns `sample_output` to each list element, and every element was allocated with calloc and given `x_vel = 128` in `new_output_notify`. So `sample_output->x_vel += x_diff` reads an initialized value. The new compound-assignment handling in the PR makes Cppcheck report this as an uninitialized read, likely because it does not model the macro's assignment of the iterator, or the macro is unknown to it. This is a new false positive. ---- 35 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/plastimatch/plastimatch_1.10.0+dfsg.2.orig.tar.xz Result: main plastimatch-1.10.0+dfsg.2/src/register/bspline_regularize_numeric.cxx:236:7: error: Uninitialized variable: d_sq [legacyUninitvar] Explanation: Line 236 accumulates into `d_sq` with `+=`, while only `d2_sq`, `d1_sq` and `d0_sq` are reset just before the loop. So the uninitialized-variable report looks like a true positive. The PR now treats compound assignments as reads in ValueFlow, so the valueflow-based `uninitvar` checker reports it instead of `legacyUninitvar`. The location and message are unchanged, and only the checker id differs. Users still get the same warning. ---- 36 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/plastimatch/plastimatch_1.10.0+dfsg.2.orig.tar.xz Result: your plastimatch-1.10.0+dfsg.2/src/register/bspline_regularize_numeric.cxx:236:7: error: Uninitialized variable: d_sq [uninitvar] Explanation: `d_sq` is accumulated with `+=` inside the loop. Unlike `d2_sq`, `d1_sq` and `d0_sq`, it is never set to 0 beforehand; this looks like a typo where `d1_sq` was initialized instead. So reading it is a real uninitialized-variable bug. Previously only the legacy checker reported it (`legacyUninitvar`). With the PR, ValueFlow treats a compound assignment as a read of the variable, so the modern `uninitvar` checker now reports the same true positive. The message text and location are unchanged; only the checker/ID changed. This shows the more precise ValueFlow analysis now understands `+=` correctly, so it is a slight improvement, though for users it is nearly neutral. ---- 37 / 50 ---- Verdict: ACCEPTABLE 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/ChezScheme/c/self-exe.c:284:11: style: Variable 't' can be declared as pointer to const [constVariablePointer] Explanation: `t` is set to `p` and is then only passed to `path_append(const char *, ...)`. Nothing is ever written through `t`. The write `*p++ = '\0'` goes through `p`, after `p += strcspn(...)` has moved it away from `t`. So `const char *t` would compile and is correct, and the removed constVariablePointer warning was a true positive. The PR now treats compound assignments like `p += ...` as invalidating the tracked value. This likely makes Cppcheck lose the relationship between `t` and `p` and conservatively assume the data `t` points to may be modified through `p`. The result is a new false negative, not a removed false positive. ---- 38 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sch-rnd/sch-rnd_1.0.12.orig.tar.bz2 Result: main sch-rnd-1.0.12/scconfig/src/util/sccbox.c:828:5: error: Uninitialized variable: seed [legacyUninitvar] Explanation: `seed` is declared without an initializer and first read in `seed <<= 8` when `fopen` succeeds, so this is a real uninitialized read. The PR treats compound assignment as a read in ValueFlow. As a result, the valueflow uninitvar check now catches it, and the legacy checker's duplicate report is dropped. The same true positive is still reported at the same location, now as `uninitvar` (warning, with path notes) instead of `legacyUninitvar` (error). The finding is effectively unchanged for users: the path notes are slightly better and the severity is slightly lower. ---- 39 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/sga/sga_0.10.15.orig.tar.gz Result: your sga-0.10.15/src/Thirdparty/stdaln.c:885:25: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] sga-0.10.15/src/Thirdparty/stdaln.c:883:27: note: Assuming allocation function fails sga-0.10.15/src/Thirdparty/stdaln.c:883:8: note: Assuming condition '_mem' is false sga-0.10.15/src/Thirdparty/stdaln.c:883:12: note: Assignment 'mem=_mem?_mem:calloc((len1+2)*(N_MATRIX_ROW+1),4)', assigned value is 0 sga-0.10.15/src/Thirdparty/stdaln.c:884:5: note: _p is assigned 'mem' here. sga-0.10.15/src/Thirdparty/stdaln.c:885:25: note: Null pointer addition Explanation: Line 883 sets `mem` to the result of `calloc` when `_mem` is NULL, and the result is never checked. `_p = mem; _p += 4 * (len1 + 2);` therefore does pointer arithmetic on NULL if the allocation fails. Before the PR, the analyzer treated the compound assignment `+=` as a plain write, so the null value was dropped without being read. With the PR, `+=` also counts as a read of the old value, so the null value reaches it. This matches the updated test in testnullpointer (`p += a` now reports nullPointerArithmetic). The new warning is a genuine out-of-memory true positive. ---- 40 / 50 ---- Verdict: ACCEPTABLE REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/squeak-vm/squeak-vm_4.10.2.2614+20120917~dfsg.orig.tar.xz Result: main opensmalltalk-vm-00aa355bd2f0fcfbe9b7110a70b486f89c85c55d/platforms/Cross/plugins/RePlugin/pcre.c:2135:9: style: Variable 'start_bracket' can be declared as pointer to const [constVariablePointer] Explanation: `start_bracket` is initialized from `code` and, in this PCRE version, appears to be used only for pointer arithmetic (e.g. `code - start_bracket`) to compute the bracket length. It is never written through, so declaring it as a pointer to const looks valid, and the removed constVariablePointer warning was most likely a true positive. The PR now treats compound assignments such as `code += 3 + skipbytes` as invalidating tracked values. This apparently changes how the alias between `code` and `start_bracket` is handled and suppresses the warning without good reason. The later uses of `start_bracket` are not in the shown snippet, so confidence is low. ---- 41 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/syrthes/syrthes_4.3.5+20200129-dfsg1.orig.tar.gz Result: main syrthes-4.3.5+20200129-dfsg1/src/syrthes-kernel/src/couplageSR.c:1507:3: error: Uninitialized variable: dist_moy [legacyUninitvar] Explanation: The legacy checker's unconditional error at `dist_moy /= nbtot` is replaced by an uninitvar warning on the same line. The variable is only initialized inside the `if` at line 1458 (and the MPI `else`, which is compiled out), so the issue is still reported. The PR now treats compound assignment as a read in ValueFlow, so the new warning gives the triggering path ('Assuming condition is false'). Its warning severity reflects that it depends on a condition. Same finding, more accurate and explained message. ---- 42 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/syrthes/syrthes_4.3.5+20200129-dfsg1.orig.tar.gz Result: your syrthes-4.3.5+20200129-dfsg1/src/syrthes-kernel/src/couplageSR.c:1507:3: warning: Uninitialized variable: dist_moy [uninitvar] syrthes-4.3.5+20200129-dfsg1/src/syrthes-kernel/src/couplageSR.c:1458:26: note: Assuming condition is false syrthes-4.3.5+20200129-dfsg1/src/syrthes-kernel/src/couplageSR.c:1507:3: note: Uninitialized variable: dist_moy Explanation: The PR stops compound assignments from being treated as plain writes, so the ValueFlow uninit checker now sees that `dist_moy /= nbtot` reads `dist_moy`. The same location was already flagged by main as a legacyUninitvar error. In the visible code, `dist_moy` is only initialized in the `#ifdef _SYRTHES_MPI_` else branch. Without MPI, the condition at line 1458 being false leaves it uninitialized, though lines 1450-1467 are not shown. The new report is a conditional 'warning' with a path note ('Assuming condition is false'). That is more accurate and more helpful than the unconditional legacy error, so this is a message-quality improvement rather than a new finding. ---- 43 / 50 ---- Verdict: ACCEPTABLE REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/t/tclthread3/tclthread3_3.0.7.orig.tar.gz Result: main thread3.0.7/win/nmakehlp.c:660:9: style: Variable 'm' can be declared as pointer to const [constVariablePointer] Explanation: The marked line 660 is blank, so the shown source probably does not match the analyzed file exactly. The only `m` nearby is `char *m = strstr(szBuffer, p->key);` at line 668. That `m` is only null-checked and compared (`op != m`), never written through, so declaring it `const char *` would be valid and the warning looks like a true positive. The PR only changes how compound assignments invalidate values, and how that removes this warning is not obvious, possibly through `op`/`cp` dataflow. Losing a probably-correct style warning is a new false negative, hence acceptable regression. Confidence is low because of the line mismatch and the unclear cause. ---- 44 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/t/tclvfs/tclvfs_1.4.2~20230906.orig.tar.gz Result: main tclvfs/win/nmakehlp.c:661:9: style: Variable 'm' can be declared as pointer to const [constVariablePointer] Explanation: Line 661 in the shown file is blank, but column 9 matches `char *m = strstr(szBuffer, p->key);` a few lines below, so the report most likely refers to that `m`. `m` is only used in the comparison `op != m` and is never written through, so it could be `const char *m`. The removed constVariablePointer warning was therefore a true positive, and losing it is a new false negative. The PR changes how compound assignments (`op += strlen(...)`) invalidate values, which apparently affects this check indirectly. That loss does not make any wrong warning appear. ---- 45 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/t/trafficserver/trafficserver_9.2.5+ds.orig.tar.xz Result: main trafficserver-9.2.5/proxy/logging/LogAccess.cc:618:9: style: Variable 'val_buf' can be declared as pointer to const [constVariablePointer] Explanation: `val_buf` is initialized from `*buf` and is only read afterwards: it is passed to `::strlen`, to `LogAccess::strlen` (presumably taking `const char*`), and used as the memcpy source. Nothing is written through it, so it could be `const char*` and the constVariablePointer warning was a true positive. The PR now treats the compound assignment `*buf += ...` as invalidating tracked values. That apparently suppressed this warning, a new false negative rather than a fixed false positive. ---- 46 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/t/trafficserver/trafficserver_9.2.5+ds.orig.tar.xz Result: main trafficserver-9.2.5/src/tscore/BufferWriterFormat.cc:244:13: style: Variable 'last' can be declared as pointer to const [constVariablePointer] Explanation: In the visible code, `last` is only assigned from other pointers, compared, and used in `last - dst`. It is never dereferenced or written through, so `const char *last` would compile. The constVariablePointer warning therefore looks like a true positive. The PR only changes how compound assignments affect value-flow analysis, which does not make this warning wrong. Losing it is a new false negative. The rest of the function is not shown, so confidence is medium. ---- 47 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vino/vino_3.22.0.orig.tar.xz Result: main vino-3.22.0/server/miniupnp/minissdpc.c:29:18: style: Variable 'url' can be declared as pointer to const [constVariablePointer] Explanation: In the miniupnp source, `url` is only assigned from `p` (`url = p;`) and then read as the source of `memcpy(tmp->buffer, url, urlsize)`. It is never written through, so declaring it `const unsigned char *` is valid, and the constVariablePointer warning was a true positive. The PR now treats compound assignments such as `p += urlsize` as Read|Invalid in valueflow. This likely changed how the alias between `url` and `p` is tracked, and the warning disappeared as a side effect. Losing this true positive is a new false negative, but it is minor. ---- 48 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vtgrab/vtgrab_0.1.8.orig.tar.gz Result: main vtgrab-0.1.8.orig/rvcd.c:176:19: style: Variable 'r' can be declared as pointer to const [constVariablePointer] Explanation: `r` is initialized from `p` and only used as `*r++` on the right-hand side of an assignment. Nothing is ever written through it, so declaring it `const unsigned char *r` would be valid. The removed constVariablePointer warning was therefore a true positive. Its disappearance is a new false negative, most likely a side effect of the compound assignment `p -= ...` now being treated as an invalidating read/write in valueflow. ---- 49 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/w/wims/wims_4.31b+dfsg1.orig.tar.gz Result: your tmpyhiilwkj/src/var.c:164:21: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] tmpyhiilwkj/src/var.c:161:56: note: Assuming allocation function fails tmpyhiilwkj/src/var.c:161:48: note: Assignment '_varptr=_varbuf[_varbufcurr]=xmalloc(256*1024)', assigned value is 0 tmpyhiilwkj/src/var.c:157:26: note: Assuming condition is true tmpyhiilwkj/src/var.c:164:21: note: Null pointer addition Explanation: The new warning assumes `xmalloc(VARBUF_LEN)` can return NULL and then flags `_varptr+=vlenmax[lvl]` as null-pointer arithmetic. In WIMS, `xmalloc` is a checked wrapper: it calls `exit` when `malloc` fails, so it never returns NULL. That makes this a false positive. It appears only because the PR now treats compound assignment (`+=`) as a read of the tracked value, which lets the out-of-memory null value reach this line. Adding a false positive is a regression. ---- 50 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xfel/xfel_1.4.0.orig.tar.gz Result: main xfel-1.4.0/ecdsa256.c:122:13: style: Variable 'end' can be declared as pointer to const [constVariablePointer] Explanation: In vli_rshift1, 'end' is initialized from 'vli' and only used in the comparison 'vli-- > end'. It is never dereferenced or written through, so declaring it 'const uint64_t *end' is valid C, and the constVariablePointer warning was a true positive. The PR now treats compound assignments such as 'vli += ECDSA256_NUM_DIGITS' as Read|Invalid. This apparently changes the value or alias tracking between vli and end, so the warning is no longer reported. Losing a correct style warning is a new false negative.