AI review of 2026-11-05_12-56-26-58126147d4cc-results.txt PR: #8996 https://github.com/cppcheck-opensource/cppcheck/pull/8996 Tested: 58126147d4cc2152fd0934d6c8863a4f9ca22b55 Merge base: a7b9e1cc22dd4d6f345dfec61d6172bb3253bad2 Reviewed: 2026-11-06 23:23:44 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 111 in the report (random sample) Verdicts: 30 acceptable regression, 11 improvement, 3 neutral, 5 regression, 1 unclear Tokens: 92647 input, 69000 cache read, 17250 cache write, 33425 output The verdicts are written by AI and can be wrong. ---- 1 / 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 only read, but its value is copied into the non-const pointer `from` (`from = window - OFF`), and `from` is later moved with `from += ...`. Declaring `window` as pointer to const would only compile if `from` were made const too, and Cppcheck never suggests that for `from`. The PR marks values as invalid after compound assignment, which changes how `from` is analysed and removes this warning. Whether that is a fixed false positive or a lost true positive (both pointers could legitimately be const) cannot be settled from the excerpt. ---- 2 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/bird3/bird3_3.4.0.orig.tar.xz Result: main bird3-3.4.0/proto/ospf/lsalib.c:525:31: style: Variable 'l' can be declared as pointer to const [constVariablePointer] Explanation: `l` is set from `buf` and is only used to read `l->type`. Nothing is written through it, so it could be `const struct ospf_lsa_rt3_link *`, which C allows when assigning from `void *`. The removed constVariablePointer warning was a true positive. The PR now treats compound assignments such as `buf += ...` as invalidating tracked values. That apparently changed the analysis enough to drop this valid style warning (and the identical one at line 489), creating a false negative. ---- 3 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/c-blosc/c-blosc_1.21.7+ds.orig.tar.xz Result: main Blosc-c-blosc-d581577/blosc/blosc.c:1592:12: style: Variable 'bstarts' can be declared as pointer to const [constVariablePointer] Explanation: In c-blosc's blosc_getitem, 'bstarts' is set to point into the source header (_src + 16) and is then only read, for example via sw32_(bstarts + j*4). It is never written through, so declaring it as 'const uint8_t *' would be valid, and the constVariablePointer warning was a true positive. The PR treats compound assignments as invalidating tracked values, which appears to have suppressed this warning as a side effect. That makes this a new false negative rather than a fixed false positive. The usage lines are not shown in the snippet, so confidence is medium. ---- 4 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/c-munipack/c-munipack_2.1.39.orig.tar.xz Result: main C-Munipack-2.1.39-source/thirdparty/cfitsio/getcolb.c:1914:11: style: Variable 'cstring' can be declared as pointer to const [constVariablePointer] Explanation: In cfitsio's fffstri1, `cstring` is assigned from `cptr` and then only read, e.g. formatted into an error message with `%s`. Nothing is written through it, so it could be `const char *`, and the constVariablePointer warning was a true positive. The PR's new handling of compound assignment (`cptr += twidth`) as Read|Invalid apparently changes the alias/value tracking so the check no longer fires. That makes this a new false negative, not a removed false positive. ---- 5 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/c-munipack/c-munipack_2.1.39.orig.tar.xz Result: main C-Munipack-2.1.39-source/thirdparty/cfitsio/getcold.c:1588:11: style: Variable 'cstring' can be declared as pointer to const [constVariablePointer] Explanation: In fffstrr8, `cstring` is only assigned from `cptr` and later read (for example, printed in an error message). Nothing is written through it, so declaring it `const char *` would be valid and the constVariablePointer warning was a true positive. The PR changes valueflow handling of compound assignments such as `cptr += twidth`, which appears to make Cppcheck lose track of this. The same warning disappears systematically across the cfitsio getcol*.c files. That is a new false negative, not a removed false positive. ---- 6 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/c-munipack/c-munipack_2.1.39.orig.tar.xz Result: main C-Munipack-2.1.39-source/thirdparty/cfitsio/getcolj.c:3709:11: style: Variable 'cstring' can be declared as pointer to const [constVariablePointer] Explanation: In fffstri8, `cstring` is assigned `cptr` and in cfitsio it is only read afterwards, as the `%s` argument when building the error message. It is never written through, so it could be `const char *` and the constVariablePointer warning was a true positive. The PR changes valueflow handling of compound assignments such as `cptr += twidth`, which apparently has a side effect on this check. The warning disappears here and in the sibling getcol*.c files, so this is a new false negative rather than a fixed false positive. ---- 7 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/c-munipack/c-munipack_2.1.39.orig.tar.xz Result: main C-Munipack-2.1.39-source/thirdparty/cfitsio/getcolk.c:1809:11: style: Variable 'cstring' can be declared as pointer to const [constVariablePointer] Explanation: In cfitsio's fffstrint, 'cstring' is set to 'cptr' and, as far as can be judged from the visible code and the usual cfitsio source, it is only read afterwards: it is printed in the error message with snprintf, and writes such as '*tpos = 0' go through 'tpos', not 'cstring'. So 'cstring' really could be 'const char *', and the removed constVariablePointer warning was a true positive. The PR now marks values as Invalid after compound assignments like 'cptr += twidth', which appears to have side-effected away this style warning. That is a new false negative on a low-severity style check, so it is an acceptable regression. ---- 8 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/c-munipack/c-munipack_2.1.39.orig.tar.xz Result: main C-Munipack-2.1.39-source/thirdparty/cfitsio/getcolui.c:1821:11: style: Variable 'cstring' can be declared as pointer to const [constVariablePointer] Explanation: In cfitsio's fffstru2, `cstring` is set to `cptr` and then, as far as can be told, only read: it is passed to snprintf for an error message. Writes such as `*tpos = 0` and the `cptr` increments go through other pointers. So `cstring` could be declared `const char *`, and the removed constVariablePointer warning was a true positive. The PR makes compound assignments such as `cptr += twidth` invalidate value tracking. That likely changed what Cppcheck infers about aliasing between `cstring` and `cptr`, so the valid style warning is lost. This is a new false negative, not a removed false positive. ---- 9 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/c-munipack/c-munipack_2.1.39.orig.tar.xz Result: main C-Munipack-2.1.39-source/thirdparty/cfitsio/getcoluj.c:1821:11: style: Variable 'cstring' can be declared as pointer to const [constVariablePointer] Explanation: In fffstru4, 'cstring' is set from 'cptr' (`cstring = cptr;`). In cfitsio this function only reads it afterwards, when it prints the bad field text with sprintf("%s"). Nothing is written through 'cstring', since writes go through 'cptr' and 'tpos'. So 'cstring' could be 'const char *', and the warning was a true positive. The PR makes compound assignments such as `cptr += twidth` invalidate tracked values. This apparently stops Cppcheck from proving that 'cstring' is never written through, so the same correct warning disappears in many files. That is a new false negative, not a removed false positive. Confidence is medium because the later uses of 'cstring' are not shown in the excerpt. ---- 10 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/c-munipack/c-munipack_2.1.39.orig.tar.xz Result: main C-Munipack-2.1.39-source/thirdparty/cfitsio/getcoluk.c:1829:11: style: Variable 'cstring' can be declared as pointer to const [constVariablePointer] Explanation: In cfitsio's fffstruint, `cstring` is only assigned from `cptr` and later read, typically as a `%s` argument in an error message. Nothing is written through it, so it could be `const char *` and the constVariablePointer warning was a true positive. The PR changes how compound assignments such as `cptr += twidth` are handled in valueflow, and that apparently suppresses the warning. Losing it is a new false negative, not a removed false positive. ---- 11 / 50 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/c/c-munipack/c-munipack_2.1.39.orig.tar.xz Result: main C-Munipack-2.1.39-source/thirdparty/cfitsio/zlib/inffast.c:83: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; from += ...`) and then read through `PUP(from)`. Declaring only `window` as `const unsigned char *` would break those assignments; `from` would also have to become const, and Cppcheck did not flag `from` at all. The constVariablePointer warning was therefore not directly actionable and was likely a false positive. With the PR, compound assignments like `from += ...` are treated as invalidating the tracked value. That probably fixes the alias tracking and removes the warning. The source shown does not include the later uses of `window`, so confidence is low. ---- 12 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/coot/coot_1.1.18+dfsg.orig.tar.xz Result: main coot-1.1.18+dfsg/ccp4mg-utils/mmut/mmut_sasarea.cc:185:7: error: Uninitialized variable: nat_set [legacyUninitvar] Explanation: `nat_set` is declared without an initializer and then updated with `nat_set += nat0`, so reading it is a real uninitialized read. Main reported this as legacyUninitvar. With the PR, compound assignment is treated as a read of the variable. The same true positive is now reported by the valueflow-based uninitvar check, with a path note. The removed main line is replaced by an equivalent, more precise warning at the same location, so users lose nothing and get a better diagnostic. ---- 13 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/coot/coot_1.1.18+dfsg.orig.tar.xz Result: your coot-1.1.18+dfsg/MoleculesToTriangles/CXXClasses/lfit.c:58:7: error: If memory allocation fails: overflow in pointer arithmetic, NULL pointer is subtracted. [nullPointerArithmeticOutOfMemory] coot-1.1.18+dfsg/MoleculesToTriangles/CXXClasses/lfit.c:56:27: note: Assuming allocation function fails coot-1.1.18+dfsg/MoleculesToTriangles/CXXClasses/lfit.c:56:9: note: Assignment 'm=(float**)malloc((unsigned int)(nrh-nrl+1)*sizeof(float*))', assigned value is 0 coot-1.1.18+dfsg/MoleculesToTriangles/CXXClasses/lfit.c:58:7: note: Null pointer subtraction Explanation: In `matrix()`, `m` comes from `malloc`. If `!m`, the code calls `nrerror`, which only prints a message and does not exit. So execution reaches `m -= nrl;` with `m == NULL`, which is pointer arithmetic on a NULL pointer. This is the same pattern as `return v-nl;` in `NRvector` and `ivector_nr`. Before the PR, the compound assignment `-=` hid the NULL value from the analysis; the PR now marks it as a read and reports it. This is a genuine new true positive in the out-of-memory path. ---- 14 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/coot/coot_1.1.18+dfsg.orig.tar.xz Result: your coot-1.1.18+dfsg/ccp4mg-utils/mmut/mmut_sasarea.cc:185:7: warning: Uninitialized variable: nat_set [uninitvar] coot-1.1.18+dfsg/ccp4mg-utils/mmut/mmut_sasarea.cc:182:17: note: Assuming condition is true coot-1.1.18+dfsg/ccp4mg-utils/mmut/mmut_sasarea.cc:185:7: note: Uninitialized variable: nat_set Explanation: `nat_set` is declared without an initializer at line 169. At line 185, `nat_set += nat0` reads it, so this is a real uninitialized-variable bug. Main already reported it as legacyUninitvar. With the PR, the ValueFlow-based uninitvar check reports the same line instead, with path notes and warning severity. The 'Assuming condition is true' note is somewhat irrelevant, but it is harmless. The same true positive is still reported, only through a different checker, so the change makes no real difference to users. ---- 15 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz Result: your criu-4.3/test/zdtm/static/cow01.c:308:7: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] criu-4.3/test/zdtm/static/cow01.c:296:13: note: Assuming allocation function fails criu-4.3/test/zdtm/static/cow01.c:296:13: note: Assignment 'addr=mmap(NULL,PAGE_SIZE*((2<<6)+2),PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0)', assigned value is 0 criu-4.3/test/zdtm/static/cow01.c:308:7: note: Null pointer addition Explanation: mmap does not return NULL on failure; it returns MAP_FAILED, and the code checks for that and returns early. Cppcheck models mmap as an allocation function that can return 0. The PR now treats the compound assignment 'addr += PAGE_SIZE' as a read of the old value, so it reports pointer addition on that NULL value. mmap(NULL, ...) without MAP_FIXED will not return address 0 in practice, so the warning is a false positive. ---- 16 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/ctn/ctn_3.2.0~dfsg.orig.tar.xz Result: main ctn-3.2.0+dfsg.orig/facilities/objects/dcm.c:7113:5: error: Uninitialized variable: opt [legacyUninitvar] Explanation: At line 7114, `opt |= ...` reads `opt` before it was ever initialized, so the bug is real. The PR does not drop the warning. The same report now comes from the ValueFlow-based uninitvar check instead of legacyUninitvar, with the matching 'your' line at 7113:5. The diagnostic is kept and now comes from the more precise checker. ---- 17 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/ctn/ctn_3.2.0~dfsg.orig.tar.xz Result: your ctn-3.2.0+dfsg.orig/facilities/objects/dcm.c:6825:7: error: Pointer addition with NULL pointer. [nullPointerArithmetic] ctn-3.2.0+dfsg.orig/facilities/objects/dcm.c:6773:24: note: Assignment 'p=NULL', assigned value is 0 ctn-3.2.0+dfsg.orig/facilities/objects/dcm.c:6778:38: note: Assuming condition is false ctn-3.2.0+dfsg.orig/facilities/objects/dcm.c:6825:7: note: Null pointer addition Explanation: In copyData, `p` is a local pointer initialised to NULL at line 6773. The lines shown never reassign it: it is only cast to an integer offset. The flagged `p += l` (column 7 is the `+=`) therefore adds an offset to a NULL pointer, which is undefined behaviour in C. Before the PR, Cppcheck treated the compound assignment as an ordinary write and dropped the known NULL value, so this was missed. The PR's own test now expects nullPointerArithmetic for the same pattern. The lines between 6773 and 6785 are not shown, so a reassignment there cannot be fully ruled out, but the reported value path suggests none. This is a new true positive. ---- 18 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/ctn/ctn_3.2.0~dfsg.orig.tar.xz Result: your ctn-3.2.0+dfsg.orig/facilities/objects/dcm.c:7113:5: error: Uninitialized variable: opt [uninitvar] Explanation: `opt` is declared at line 7082 without an initializer. Line 7114 then does `opt |= ...`, which reads the uninitialized value, so the warning is a true positive. The pull request does not add or remove this warning. It only changes the id from legacyUninitvar to uninitvar, meaning the valueflow-based checker now catches it because compound assignment is treated as a read. That reflects better understanding of the code, and the message is equally accurate. The change is neutral to positive for users. ---- 19 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/d/dolphin-emu/dolphin-emu_2609.a+dfsg.orig.tar.xz Result: main dolphin-emu-2609a/Source/Core/Core/PowerPC/GDBStub.cpp:614:10: style: Variable 'bufptr' is assigned a value that is never used. [unreadVariable] Explanation: In WriteRegisters, `bufptr += 32 * 8;` at line 614 is the last use of `bufptr`. The function then only calls SendReply("OK"), so the incremented value is never read. The unreadVariable warning was a true positive. The PR now marks compound assignments as Read|Invalid in the ValueFlow analyzer, and as a side effect this warning is lost. That is a new false negative, not a removed false positive. ---- 20 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/d/dwz/dwz_0.17.orig.tar.xz Result: main dwz-0.17/dwz.c:5777:22: style: Variable 's1' can be declared as pointer to const [constVariablePointer] Explanation: In strrevcmp, `s1` is only read (`s1->new_off`, `s1->off`) and never written through or passed as non-const. It can be declared `const struct strp_entry *s1`, so the constVariablePointer warning was a true positive. The PR's change to compound assignment handling (`p1 += len1` nearby) seems to have suppressed it as a side effect. Losing a true positive is a new false negative. ---- 21 / 50 ---- Verdict: ACCEPTABLE REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/d/dwz/dwz_0.17.orig.tar.xz Result: main dwz-0.17/dwz.c:5778:22: style: Variable 's2' can be declared as pointer to const [constVariablePointer] Explanation: In strrevcmp, 's2' is only read through (s2->new_off, s2->off), so declaring it 'const struct strp_entry *' is valid and the constVariablePointer warning was a true positive. The PR changes how compound assignments (e.g. 'p2 += len2', where p2 is derived from s2->off) are handled in the value-flow analyzer, and this caused the warning to be lost. Nothing writes through s2, so losing the warning is a new false negative. ---- 22 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/freewnn/freewnn_1.1.1~a021+cvs20130302.orig.tar.xz Result: main freewnn-1.1.1~a021+cvs20130302/Xwnmo/xwnmo/touroku.c:57:11: style: Variable 'buffer_end' can be declared as pointer to const [constVariablePointer] Explanation: `buffer_end` is assigned once and only used in the comparison `bp >= buffer_end`. It is never dereferenced for writing, so it could be declared `const w_char *`, and the constVariablePointer warning was a true positive. The PR changes how compound assignments are handled (`bp += l`, `bp -= l` nearby), which apparently disturbed the analysis. As a result this valid style warning is no longer reported, which is a new false negative. ---- 23 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/fuzzel/fuzzel_1.15.0+ds.orig.tar.xz Result: your fuzzel/uri.c:201:15: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] fuzzel/uri.c:180:32: note: Assuming allocation function fails fuzzel/uri.c:180:32: note: Assignment 'decoded=xmalloc(path_len+1)', assigned value is 0 fuzzel/uri.c:181:19: note: Assignment 'p=decoded', assigned value is 0 fuzzel/uri.c:190:22: note: Assuming condition is false fuzzel/uri.c:201:15: note: Null pointer addition Explanation: In fuzzel, `xmalloc` is a checked wrapper: it aborts via a fatal error when `malloc` fails, so it never returns NULL. That makes the out-of-memory path behind this warning impossible, and `p += prefix_len` can never be arithmetic on a NULL pointer. The PR now treats a compound assignment as a read of the tracked value, which exposes this spurious OOM path at line 201. The new warning is a false positive. ---- 24 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/gavl/gavl_2.0.1.orig.tar.gz Result: main bplaum-gavl-b9385e3/src/colorspace_test.c:1039:13: style: Variable 'in_y' can be declared as pointer to const [constVariablePointer] Explanation: In convert_YUV_411_P_to_RGB24, `in_y` is assigned from `in_y_save`, only read through `*in_y` (as an input to YUV_2_RGB), and incremented. It is never written through, so declaring it `const uint8_t *` is valid. The constVariablePointer warning was a true positive. The PR's change to compound-assignment handling in the valueflow analyzer apparently made Cppcheck lose this warning (and the similar ones in the file), which is a new false negative. ---- 25 / 50 ---- Verdict: ACCEPTABLE REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/g/gimp-gap/gimp-gap_2.6.0+dfsg.orig.tar.gz Result: main gimp-gap-2.6.0+dfsg.orig/libgapvidutil/gap_gve_jpeg.c:231:17: style: Variable 's' can be declared as pointer to const [constVariablePointer] Explanation: The PR only changes how the value-flow analyzer treats compound assignments (e.g. `s += n`): it now marks them as invalidating the tracked value. This is unrelated to whether the data pointed to by `s` is written. In this JPEG encoder `s` is almost certainly a read cursor over the source pixel rows (copy `*s` into `t`, then advance it, possibly with `s += ...` to skip alpha). That is exactly the pattern where `s` can be `const guchar *`, so the removed constVariablePointer warning was likely a true positive lost as a side effect of the change. The code that uses `s` is not shown, so this cannot be confirmed. ---- 26 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/guacamole-server/guacamole-server_1.3.0.orig.tar.gz Result: main guacamole-server-1.3.0/src/libguac/parser.c:171:11: style: Variable 'buffer_end' can be declared as pointer to const [constVariablePointer] Explanation: `buffer_end` is set once to the end of `__instructionbuf` and never written through. In the visible code it is only compared with `unparsed_end`. In the upstream source it is also used in the size `buffer_end - unparsed_end`. Declaring it `const char*` would therefore be valid, so the removed constVariablePointer warning was a true positive. The PR changes how compound assignments (e.g. `unparsed_end -= offset`) invalidate values, which apparently suppressed this warning as a side effect. That is a new false negative, not a fixed false positive. Confidence is medium because the rest of the function is not shown. ---- 27 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/idzebra/idzebra_2.2.11.orig.tar.gz Result: your idzebra-2.2.11/dict/insert.c:217:30: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] idzebra-2.2.11/dict/insert.c:150:32: note: Assuming allocation function fails idzebra-2.2.11/dict/insert.c:150:16: note: Assignment 'np=(char*)xmalloc(dict->head.page_size)', assigned value is 0 idzebra-2.2.11/dict/insert.c:217:30: note: Null pointer addition Explanation: `np` comes from yaz's `xmalloc`, which aborts on out-of-memory and never returns NULL. Even if it could return NULL, the loop above line 217 already writes through `info2` and `indxp2`, both derived from `np`, so this later pointer addition at line 217 is not the real failure point. The PR stopped value tracking from being invalidated through the `+=` updates in the loop, so the allocation-failure value now reaches line 217. The result is an essentially false or redundant nullPointerArithmeticOutOfMemory warning. ---- 28 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/j/jansson/jansson_2.15.1.orig.tar.gz Result: main akheron-jansson-1749b18/src/dtoa.c:2705:13: style: Variable 'x0' can be declared as pointer to const [constVariablePointer] Explanation: In any_on(), x0 is only assigned from x and used in the comparison `x > x0`. It is never dereferenced or written through, so it could be declared `const ULong *x0`. The removed constVariablePointer warning was a true positive. The PR changed compound-assignment handling in valueflow, and `x += n` now invalidates tracking, which appears to have suppressed this warning as a side effect. That makes it a new false negative, not a removed false positive. ---- 29 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libd/libdv/libdv_1.0.0.orig.tar.gz Result: your libdv-1.0.0/encodedv/ppmqscale.c:189:7: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] libdv-1.0.0/encodedv/ppmqscale.c:319:35: note: Assuming allocation function fails libdv-1.0.0/encodedv/ppmqscale.c:319:12: note: Assignment 'out_pic=(unsigned char*)malloc(out_width*out_height*3)', assigned value is 0 libdv-1.0.0/encodedv/ppmqscale.c:324:22: note: Calling function 'fast_scale', 2nd argument 'out_pic' value is 0 libdv-1.0.0/encodedv/ppmqscale.c:299:22: note: Calling function 'shrink_picture', 2nd argument 'out' value is 0 libdv-1.0.0/encodedv/ppmqscale.c:180:13: note: Assuming condition is false libdv-1.0.0/encodedv/ppmqscale.c:189:7: note: Null pointer addition Explanation: `out_pic` comes from `malloc` and, per the trace, is passed through `fast_scale` to `shrink_picture` as `dst` without a NULL check. In the else-branch, `dst += offset` (line 189) then does pointer arithmetic on a NULL pointer if the allocation failed, which is undefined behavior. The PR now handles compound assignment like `p += a` so the null value reaches the arithmetic check, which is exactly what the updated unit test expects. This new warning is a genuine (out-of-memory) true positive about the unchecked `malloc`. ---- 30 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libk/libkarma/libkarma_0.1.2.orig.tar.gz Result: your libkarma-0.1.2/src/karmaUsb.c:544:21: warning: Either the condition 'str' is redundant or there is pointer arithmetic with NULL pointer. [nullPointerArithmeticRedundantCheck] libkarma-0.1.2/src/karmaUsb.c:539:20: note: Assuming that condition 'str' is not redundant libkarma-0.1.2/src/karmaUsb.c:538:21: note: str is assigned 'ptr' here. libkarma-0.1.2/src/karmaUsb.c:544:21: note: Null pointer addition Explanation: At line 538 the code sets `str = ptr` and then tests `if(str)`, which implies `ptr` may be NULL. Line 544 then does `ptr += strlen(str) + 1` unconditionally. If the check is meaningful, that line does arithmetic on a NULL pointer (and `strlen(NULL)` crashes first). If it is not, the check is redundant. That is exactly what nullPointerArithmeticRedundantCheck reports, so the code really is inconsistent. The PR now treats the compound assignment `ptr +=` as a read of the old value, which is correct, and that is why this warning appears. Its own test was updated to expect the same nullPointerArithmetic warning. In practice the check is probably redundant, since `ptr` is checked non-NULL at line 512, but the warning is phrased to cover that case. This is a valid new true positive. ---- 31 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libn/libnxt/libnxt_0.5.2.orig.tar.xz Result: main libnxt-0.5.2/cmd.c:47:12: style: Variable 'pp' can be declared as pointer to const [constVariablePointer] Explanation: In parse_string, 'pp' is only read through: `*s++ = *pp`, `!*pp`, `isprint(*pp)`. It is also incremented and compared with `*p`. Assigning `uint8_t*` to `const uint8_t*` is valid, so `const uint8_t *pp` would compile, and the constVariablePointer warning was a true positive. The PR now treats compound assignments such as `*p += size` as invalidating values, which apparently stops Cppcheck from reporting this. That makes it a new false negative, not a removed false positive. ---- 32 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/libp/libpicohttpparser/libpicohttpparser_1.2+ds.orig.tar.xz Result: your libpicohttpparser-1.2+ds/test.c:525:14: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] libpicohttpparser-1.2+ds/test.c:523:20: note: Assuming allocation function fails libpicohttpparser-1.2+ds/test.c:523:20: note: Assignment 'inputbuf=mmap(NULL,pagesize*3,PROT_NONE,MAP_ANON|MAP_PRIVATE,-1,0)', assigned value is 0 libpicohttpparser-1.2+ds/test.c:525:14: note: Null pointer addition Explanation: `inputbuf` comes from `mmap()`, which signals failure with `MAP_FAILED` ((void*)-1), not NULL. The code even asserts `inputbuf != MAP_FAILED` before `inputbuf += pagesize * 2`. Assuming `mmap` returned 0 is therefore wrong, and the new nullPointerArithmeticOutOfMemory warning at line 525 is a false positive. The PR now lets the null value reach the compound assignment `+=` and report it, which exposes this wrong assumption about `mmap`. ---- 33 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsolv/libsolv_0.7.40.orig.tar.gz Result: main libsolv-0.7.40/ext/solv_zchunk.c:138:18: style: Variable 'chunk_chk_ptr' can be declared as pointer to const [constVariablePointer] Explanation: `chunk_chk_ptr` is assigned from `p` and then only used to remember the checksum location for later comparison (e.g. memcmp). It is never written through, so it could be `const unsigned char *`. The warning looks like a true positive. The PR now treats compound assignments such as `p += zck->chunk_chk_len` as invalidating values. That apparently changed the valueflow information this check relies on, so the warning was lost. This is a new false negative, not the removal of a false positive. Confidence is medium because the later uses of the pointer are not shown. ---- 34 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/libz/libzorpll/libzorpll_7.0.4.0.orig.tar.gz Result: your libzorpll-7.0.4.0/src/blob.cc:1251:18: error: If memory allocation fails: pointer addition with NULL pointer. [nullPointerArithmeticOutOfMemory] libzorpll-7.0.4.0/src/blob.cc:1247:30: note: Assuming allocation function fails libzorpll-7.0.4.0/src/blob.cc:1247:18: note: Assignment 'data=(char*)mmap(NULL,*req_datalen+offset_in_page,PROT_READ|PROT_WRITE,MAP_SHARED,self->fd,pos-offset_in_page)', assigned value is 0 libzorpll-7.0.4.0/src/blob.cc:1251:18: note: Null pointer addition Explanation: The new warning says `data += offset_in_page` adds to a NULL pointer if mmap fails. That is wrong: mmap reports failure with MAP_FAILED ((void*)-1), not NULL. The code checks exactly that (`data == (gchar*)-1`) and only does the addition in the else branch. The first argument is NULL and MAP_FIXED is not used, so a successful mmap never returns NULL either. Cppcheck wrongly treats mmap as an allocator that returns NULL on failure. The PR now feeds the compound assignment `+=` into the null-pointer-arithmetic check, which exposes this false positive. ---- 35 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mlterm/mlterm_3.9.4.orig.tar.gz Result: main mlterm-3.9.4/tool/mlconfig/mc_opentype.c:77:27: style: Parameter 'values' can be declared as pointer to const [constParameterPointer] Explanation: In `contains()`, `values` is only passed to `ascii_strcasestr(const char*, ...)` and compared with `p`. It is never written through, so it really could be `const char *`, and the removed constParameterPointer warning was a true positive. The PR now treats compound assignments (`p += strlen(value)`) as invalidating the tracked value. That appears to have lost information used by the const check, creating a false negative. This is an acceptable side effect of a correctness fix in value tracking. ---- 36 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mlterm/mlterm_3.9.4.orig.tar.gz Result: main mlterm-3.9.4/tool/mlimgloader/stb_image_resize2.h:3881:19: style: Variable 'g_coeffs' can be declared as pointer to const [constVariablePointer] Explanation: `g_coeffs` is initialized from `gather_coeffs` and only used in `float gc = *g_coeffs++;`. It is never written through, so it could be `const float *`. The removed constVariablePointer warning was a true positive. The PR's change to compound-assignment handling (`gather_coeffs += ...`) apparently made Cppcheck lose this finding, which is a new false negative for a style check. ---- 37 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nsf/nsf_2.4.0.orig.tar.gz Result: main nsf2.4.0/win/nmakehlp.c:642:9: style: Variable 'm' can be declared as pointer to const [constVariablePointer] Explanation: The warning refers to `char *m = strstr(szBuffer, p->key);`. Line numbers are off by about 8, but column 9 matches `m` after two tabs. `m` is only compared (`m != NULL`, `op != m`) and never written through, so `const char *m` would be valid and the constVariablePointer warning was a true positive. The PR treats compound assignments such as `op += strlen(p->key)` as Read|Invalid. That apparently changes the aliasing/symbolic analysis between `op` and `m`, so the correct style warning is lost. This is a new false negative. ---- 38 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/ondir/ondir_0.2.3+git20140220.55279f0.orig.tar.xz Result: main ondir-0.2.3+git20140220.55279f0/ondir.c:193:8: style: Variable 'offset' can be declared as pointer to const [constVariablePointer] Explanation: In `substitute()`, `offset` is only read. It is assigned from `offset1`/`offset2`, indexed with `offset[1]`, used in `offset - in`, and assigned to `in`, which is `const char*`. It is never written through, so `const char *offset` would compile and the constVariablePointer warning was a true positive. The PR's change to compound-assignment handling in valueflow (e.g. `outlen += offset - in`, `in += vlen`) apparently stopped Cppcheck from reporting it. That is a new false negative, not a removed false positive. ---- 39 / 50 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/o/osmid/osmid_0.8.0~repack.orig.tar.xz Result: main osmid-0.8.0/JuceLibraryCode/modules/juce_core/zip/zlib/inffast.c:81: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;`), and `from` is then advanced with `from += ...`. Declaring only `window` as `const unsigned char *` would make that assignment discard a qualifier. So the removed constVariablePointer warning was most likely a false positive. The PR makes ValueFlow treat compound assignments as invalidating tracked values, which plausibly stops the wrong inference that `window`'s pointee is never modified. The exact link is not obvious from the snippet, so confidence is low. ---- 40 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/smlnj/smlnj_110.99.9.orig.tar.gz Result: main smlnj-110.99.9/ckit/regression/valid-programs/a17.c:5:3: error: Uninitialized variable: i [legacyUninitvar] Explanation: In `i += i;`, `i` is read before it is initialized, so the warning is a true positive. The removed `legacyUninitvar` at 5:3 is replaced by a `uninitvar` warning at the same location (5:3). The extra `uninitvar` warning main reported at 5:8 on the same line also disappears. Users still get one correct uninitialized-variable error for this line; only the checker id changed and a duplicate went away. ---- 41 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium 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 set from `code` and, in this PCRE version, is only used later in a pointer difference (`length = code - start_bracket`). Nothing is ever written through it, so declaring it `const uschar *` is valid and the warning is a true positive. The PR changes how compound assignments like `code += 3 + skipbytes` are handled in value flow. That change appears to have suppressed this correct style warning as a side effect, creating a new false negative. Confidence is medium because the later uses of `start_bracket` are not in the excerpt. ---- 42 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/synfigstudio/synfigstudio_1.5.5.orig.tar.xz Result: main synfig-1.5.5/synfig-core/test/benchmark.cpp:185:3: error: Uninitialized variable: t [legacyUninitvar] Explanation: `double t;` is never initialized before `t+=...` at line 185, so reading it is a real bug. The removed legacyUninitvar error is not a lost true positive. The same issue is still reported at the same line, now by the ValueFlow-based uninitvar check. The only difference is the checker id and a lower severity (warning instead of error). The bug is still caught, so users are essentially unaffected. ---- 43 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/synfigstudio/synfigstudio_1.5.5.orig.tar.xz Result: main synfig-1.5.5/synfig-osx/launcher/quartz-cursor.c:73:21: style: Variable 'sptr' can be declared as pointer to const [constVariablePointer] Explanation: The snippet stops before `sptr` is used. In the upstream XFree86 quartzCursor.c this file comes from, `sptr` is set from `srow` and only read via `s = *sptr++`, never written through. If synfig's copy matches, declaring it `const uint8_t *` is valid and the constVariablePointer warning was a true positive. The PR changes how compound assignments such as `srow += ...` invalidate values. This seems to have suppressed the warning as a side effect, not because of real data flow, so this is a new false negative. Confidence is medium because the code using `sptr` is not shown here. ---- 44 / 50 ---- Verdict: ACCEPTABLE REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/synfigstudio/synfigstudio_1.5.5.orig.tar.xz Result: main synfig-1.5.5/synfig-osx/launcher/quartz-cursor.c:74:21: style: Variable 'mptr' can be declared as pointer to const [constVariablePointer] Explanation: In this XDarwin-derived cursor code, `mptr` is normally set from `mrow` and only read (`m = *mptr++`). The pointee is never written, so declaring it `const uint8_t *` is valid and the main warning looks like a true positive. The PR's change to compound-assignment handling (e.g. `mrow += BitmapBytePad(...)`) seems to have indirectly suppressed it, which is a new false negative. The usage lines are not shown, so confidence is low. ---- 45 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/t/tdbcodbc/tdbcodbc_1.1.15.orig.tar.gz Result: main tdbcodbc1.1.15/win/nmakehlp.c:660:9: style: Variable 'm' can be declared as pointer to const [constVariablePointer] Explanation: The reported 'm' is almost certainly `char *m = strstr(szBuffer, p->key);`. The listing is offset by about 8 lines, but column 9 matches the declaration. `m` is only checked for null and compared in `op != m`. It is never written through, so it could be `const char *m`, and the constVariablePointer warning was a true positive. The PR's new handling of compound assignments (e.g. `op += strlen(p->key)`) apparently changes analysis enough to suppress it. Losing a valid style warning is a new false negative. ---- 46 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/t/texmaker/texmaker_6.0.1+dfsg.orig.tar.xz Result: main texmaker-6.0.1/3rdparty/pdfium/third_party/libopenjpeg20/invert.c:221:16: style: Variable 'lTmpMatrix' can be declared as pointer to const [constVariablePointer] Explanation: In opj_lupSolve, 'lTmpMatrix' is only assigned from lLineMatrix, incremented, and dereferenced for reading (u = *(lTmpMatrix++); sum += *(lTmpMatrix++) * ...). Nothing is ever written through it, so it could be declared 'const OPJ_FLOAT32 *'. The removed constVariablePointer warning was a true positive. Its loss is likely a side effect of the PR's new handling of compound assignment and pointer increments in the valueflow analyzer. A true positive was lost, which makes this a new false negative. ---- 47 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/u/uim/uim_1.9.9.orig.tar.bz2 Result: your uim-1.9.9/uim/uim-eb.c:218:5: warning: Uninitialized variable: bytes [uninitvar] uim-1.9.9/uim/uim-eb.c:212:44: note: Assuming condition is false uim-1.9.9/uim/uim-eb.c:218:5: note: Uninitialized variable: bytes Explanation: `bytes` is declared without an initializer. It is only set to 0 in the error branch, and that branch returns. On the normal path (condition false), `bytes += text_length` on the first loop iteration reads the uninitialized value. The warning is a true positive, and the PR now treats compound assignment as a read, which is why it is reported. ---- 48 / 50 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vde2/vde2_2.3.2+r586.orig.tar.gz Result: main vde2-2.3.2/src/slirpvde/sbuf.c:161:21: style: Parameter 'sb' can be declared as pointer to const [constParameterPointer] Explanation: `sbcopy` only reads fields of `sb` (`sb_rptr`, `sb_data`, `sb_datalen`, `sb_wptr`, `sb_cc`). The compound assignment `from -= ...` changes the local pointer `from`, not `sb`. Even `char *from = sb->sb_rptr + off` stays valid if `sb` is `const struct sbuf *`, because the member becomes `char * const` and the pointed-to data stays non-const. So the constParameterPointer warning was a true positive. The PR's new handling of compound assignments made Cppcheck lose it, which is a new false negative. ---- 49 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vde2/vde2_2.3.2+r586.orig.tar.gz Result: your vde2-2.3.2/src/vde_over_ns/vde_over_ns.c:377:10: warning: Either the condition 'data' is redundant or there is pointer arithmetic with NULL pointer. [nullPointerArithmeticRedundantCheck] vde2-2.3.2/src/vde_over_ns/vde_over_ns.c:375:9: note: Assuming that condition 'data' is not redundant vde2-2.3.2/src/vde_over_ns/vde_over_ns.c:377:10: note: Null pointer addition Explanation: Inside the loop, the code checks `if (data)` before the memcpy, which shows the author expects `data` can be NULL. It then runs `data += l;` unconditionally. If `data` is NULL and `l` is non-zero, that is pointer arithmetic on a NULL pointer, which is undefined behaviour in C. The PR makes compound assignments like `+=` count as reads that keep the known value, so Cppcheck now catches this. That matches the updated `p += a` test in the PR. The new warning is a correct true positive, though possibly low impact in practice. ---- 50 / 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 this miniupnp code, `url` is set with `url = p;` and then only used as the source of `memcpy(tmp->buffer, url, urlsize)`. Nothing is written through it, so `const unsigned char *url` would be valid and the constVariablePointer warning looks like a true positive. The PR changes how compound assignments such as `p += urlsize` are handled in valueflow, which apparently suppresses this warning as a side effect. That creates a new false negative. Confidence is medium because the usage of `url` after line 69 is not shown.