AI review of 2026-10-17_21-12-29-5ec129e2a362-results.txt PR: #8944 https://github.com/cppcheck-opensource/cppcheck/pull/8944 Tested: 5ec129e2a362d125e6d195a5795b60fb6b72cdda Merge base: b2d83612a1d235901d70a77d25c21759014e4919 Reviewed: 2026-10-18 05:48:34 UTC Model: claude-opus-5-5 (effort high) Results: 9 reviewed of 9 in the report Verdicts: 2 neutral, 7 regression Tokens: 14847 input, 21150 cache read, 10575 cache write, 3898 output The verdicts are written by AI and can be wrong. ---- 1 / 9 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/argus-clients/argus-clients_5.0.2+git20250321.41f65e2.orig.tar.xz Result: your argus-clients-5.0.2+git20250321.41f65e2/common/argus_util.c:2258:44: warning: Buffer is accessed out of bounds: "all" [bufferAccessOutOfBounds] Explanation: `strncasecmp(optarg, "all", 5)` never reads past the literal. `strncasecmp` stops comparing at the first NUL, and "all" has a terminator at index 3. The literal's array size is 4, so the length argument of 5 is not an out-of-bounds read. The PR now sizes string literals for arguments that are not marked strz, and the library's minsize=argvalue rule for strncasecmp then triggers this false positive. The new warning is a regression. ---- 2 / 9 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/argus-clients/argus-clients_5.0.2+git20250321.41f65e2.orig.tar.xz Result: your argus-clients-5.0.2+git20250321.41f65e2/examples/ramysql/raclient.c:726:50: warning: Buffer is accessed out of bounds: "drop" [bufferAccessOutOfBounds] Explanation: `strncasecmp(mode->mode, "drop", 6)` compares strings and stops at the first NUL or mismatch, so it never reads past the terminator of the 5-byte literal "drop". A length larger than the literal is harmless here. The PR now checks string literal sizes for arguments the library config does not mark as strz. Because strncasecmp's arguments are not marked that way, this new bufferAccessOutOfBounds warning is a false positive. ---- 3 / 9 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/argus-clients/argus-clients_5.0.2+git20250321.41f65e2.orig.tar.xz Result: your argus-clients-5.0.2+git20250321.41f65e2/examples/ratop/raclient.c:932:50: warning: Buffer is accessed out of bounds: "replace" [bufferAccessOutOfBounds] Explanation: The code calls `strncasecmp(mode->mode, "replace", 9)`. The literal "replace" takes 8 bytes including its terminating NUL, and the length limit is 9. However, strncasecmp stops comparing at the first NUL or the first difference, so it never reads past the end of the literal. The PR now checks string-literal sizes against minsize arguments, but strncasecmp's arguments are apparently not marked strz in the library config. Cppcheck therefore wrongly treats the call like a memcmp-style fixed-length read. This new warning is a false positive. ---- 4 / 9 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-riscv64-unknown-elf/binutils-riscv64-unknown-elf_2.32.2020.04+dfsg.orig.tar.gz Result: main binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/gdb/testsuite/gdb.arch/i386-mpx-sigsegv.c:71:15: portability: Undefined behaviour, pointer arithmetic 'c+len' is out of bounds. [pointerOutOfBounds] binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/gdb/testsuite/gdb.arch/i386-mpx-sigsegv.c:105:38: note: Calling function 'upper', 6th argument '5+2' value is 7 binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/gdb/testsuite/gdb.arch/i386-mpx-sigsegv.c:71:15: note: Pointer arithmetic overflow Explanation: In this run, the pointerOutOfBounds warning for `c+len` on line 71 was replaced by the same warning for `a+len` on line 69. Both are true positives. `upper()` is called with `len = OUR_SIZE + 2 = 7` on 5-element buffers, so every `ptr+len` in it is out of bounds. Only one of these accesses seems to get reported, and which one is unrelated to this PR. The PR only adds string-literal buffer sizes for library function arguments, and no string literals are involved here. The swap looks like nondeterministic or reporting-order noise. Users still get one equivalent true positive for the same bug. ---- 5 / 9 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-riscv64-unknown-elf/binutils-riscv64-unknown-elf_2.32.2020.04+dfsg.orig.tar.gz Result: your binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/gdb/testsuite/gdb.arch/i386-mpx-sigsegv.c:69:15: portability: Undefined behaviour, pointer arithmetic 'a+len' is out of bounds. [pointerOutOfBounds] binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/gdb/testsuite/gdb.arch/i386-mpx-sigsegv.c:105:38: note: Calling function 'upper', 6th argument '5+2' value is 7 binutils-riscv64-unknown-elf-2.32.2020.04+dfsg/gdb/testsuite/gdb.arch/i386-mpx-sigsegv.c:69:15: note: Pointer arithmetic overflow Explanation: In upper(), len is OUR_SIZE+2 = 7 while every pointer argument points to a 5-element buffer. So both 'a+len' (line 69) and 'c+len' (line 71) really are out of bounds; this gdb MPX test does it on purpose. The PR only changes getBufferSize for string-literal arguments in bufferOverflow(). The pointer-arithmetic check still calls it with checkStringLiteral=false, so this code path is unaffected. The swap of which equivalent true positive gets reported (a vs c) looks like run-to-run nondeterminism or ordering, not a real change. One true positive replaced by another identical one does not matter to users. ---- 6 / 9 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/crispy-doom/crispy-doom_7.2.orig.tar.gz Result: your fabiangreffrath-crispy-doom-fdeabe4/src/doom/d_main.c:929:49: warning: Buffer is accessed out of bounds: "MAP01" [bufferAccessOutOfBounds] Explanation: The code calls `strncasecmp(lumpinfo[i]->name, "MAP01", 8)`. `strncasecmp` stops comparing at the first NUL terminator, so it never reads past the 6-byte literal "MAP01", even though n is 8. This bounded comparison against a WAD lump name is a common, safe idiom. The PR now checks the literal's size against the `minsize` argvalue for this function, presumably because its library config does not mark the argument as `strz`. That produces a new false positive. ---- 7 / 9 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/crispy-doom/crispy-doom_7.2.orig.tar.gz Result: your fabiangreffrath-crispy-doom-fdeabe4/src/doom/d_main.c:934:54: warning: Buffer is accessed out of bounds: "E1M1" [bufferAccessOutOfBounds] Explanation: The call is `strncasecmp(lumpinfo[i]->name, "E1M1", 8)`. `strncasecmp` stops comparing at the first NUL, so the 5-byte literal is never read past its terminator. The size 8 is just an upper bound, not a guaranteed read length. The PR now treats the string literal as a 5-byte buffer whenever the argument is not marked strz in the library config, and compares that against the bound 8. This produces a new false positive on correct, idiomatic code. ---- 8 / 9 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/git/git_2.55.0+next.20260731.orig.tar.gz Result: your 21b8a5bc/compat/mingw.c:202:27: warning: Buffer is accessed out of bounds: "yes" [bufferAccessOutOfBounds] Explanation: `strncasecmp(answer, "yes", sizeof(answer))` stops comparing at the first NUL terminator or mismatch, so it never reads past the 4-byte literal "yes". The `n` argument is only an upper bound, not the number of bytes actually accessed. The PR now uses the literal's size as the buffer size for arguments not marked strz, so it treats n=1024 as an access size and reports an out-of-bounds read. This is a new false positive. ---- 9 / 9 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/git/git_2.55.0+next.20260731.orig.tar.gz Result: your 21b8a5bc/compat/mingw.c:206:27: warning: Buffer is accessed out of bounds: "no" [bufferAccessOutOfBounds] Explanation: `strncasecmp(answer, "no", sizeof(answer))` compares two NUL-terminated strings. It stops at the first NUL or mismatch, so it never reads past the end of the 3-byte literal `"no"`. A large n is a common idiom here. The new string-literal size check treats n as a guaranteed read length, apparently because strncasecmp's argument is not marked strz in the library config. This is a new false positive.