AI review of 2026-09-23_14-21-44-61f432775202-results.txt PR: #8884 https://github.com/cppcheck-opensource/cppcheck/pull/8884 Tested: 61f432775202cb1012d64c49714b9661d64536c7 Merge base: 8bb772daa62d60900b0e48535063f902aed45e41 Reviewed: 2026-10-07 02:17:02 UTC Model: claude-opus-5-5 (effort high) Results: 22 reviewed of 22 in the report Verdicts: 15 improvement, 7 neutral Tokens: 52760 input, 68187 cache read, 3247 cache write, 10611 output The verdicts are written by AI and can be wrong. ---- 1 / 22 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/g/golang-github-go-llsqlite-crawshaw/golang-github-go-llsqlite-crawshaw_0.7.0.orig.tar.xz Result: main golang-github-go-llsqlite-crawshaw-0.7.0/c/sqlite3.c:37055:47: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: The same shiftNegativeLHS warning at line 37055 is reported before and after the PR. The only difference is that the new output adds an error path. That path shows where the negative value comes from: the condition `p<-348` at line 37114 and the call `pwr10to2(p)` with p=-348 at line 37117. In `(p*108853) >> 15`, p can indeed be negative, so the left operand of the shift is negative. Severity, id and text are unchanged. The warning is debatable: right-shifting a negative value is implementation-defined, not undefined, and the code comment says it is intentional. That judgement is the same in both versions, though. The added trace makes the existing report easier to understand, a small usability improvement. ---- 2 / 22 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/g/golang-github-go-llsqlite-crawshaw/golang-github-go-llsqlite-crawshaw_0.7.0.orig.tar.xz Result: your golang-github-go-llsqlite-crawshaw-0.7.0/c/sqlite3.c:37055:47: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] golang-github-go-llsqlite-crawshaw-0.7.0/c/sqlite3.c:37114:8: note: Assuming that condition 'p<-348' is not redundant golang-github-go-llsqlite-crawshaw-0.7.0/c/sqlite3.c:37117:17: note: Calling function 'pwr10to2', 1st argument 'p' value is -348 golang-github-go-llsqlite-crawshaw-0.7.0/c/sqlite3.c:37055:47: note: Shifting a negative value is technically undefined behaviour Explanation: Main already reported the same shiftNegativeLHS warning at line 37055 with the same severity and text. The PR only attaches an error path explaining where the negative value comes from: the `p<-348` branch at line 37114 leads to calling `pwr10to2(-348)`, so `p*108853` is negative. That path is plausible and makes the diagnostic easier to understand. The underlying warning is debatable, though: right-shifting a negative value in C is implementation-defined, not undefined, and the sqlite comment says it is intentional. Since whether the warning is reported did not change and only its context was added, this is a mild improvement in message quality. ---- 3 / 22 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/k/ksh93u+m/ksh93u+m_1.0.10.orig.tar.gz Result: main ksh-1.0.10/src/lib/libast/misc/fastfind.c:1142:19: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: This 'main' line has a matching 'your' line with the same location, severity, id and message. The only difference is that the PR now attaches an error path. The new notes point to the 'z<0' condition, which explains where the negative value comes from. The warning itself is unchanged. z can be negative inside the if (z < 0 || ...) branch, so the shiftNegativeLHS portability warning stays valid. The removed line is just the old text of the same warning and does not change what users are told. ---- 4 / 22 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/k/ksh93u+m/ksh93u+m_1.0.10.orig.tar.gz Result: main ksh-1.0.10/src/lib/libast/misc/fastfind.c:1143:19: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: Line 1143 shifts z right by 16 inside the branch `if (z < 0 || z > 2 * FF_OFF)`, where z can be negative. Right-shifting a negative signed value is implementation-defined in C, and the shiftNegativeLHS warning is the same before and after. The PR only rebuilds the message with an error path, adding a note that points to the 'z<0' condition on line 1139. That is why the same warning shows up as one removed and one added line. The extra context makes the warning more informative, which is a small improvement. ---- 5 / 22 ---- Verdict: NEUTRAL (high confidence) Package: https://ftp.debian.org/debian/pool/main/k/ksh93u+m/ksh93u+m_1.0.10.orig.tar.gz Result: main ksh-1.0.10/src/lib/libast/misc/fastfind.c:1144:19: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: The same shiftNegativeLHS portability warning is still reported at line 1144. Only the error path notes were added ('Assuming that condition z<0 is not redundant'). The 'main' line shows up as removed only because the output format changed. Inside the 'z < 0' branch, z can be negative and is right-shifted, so the warning is still valid. Severity and message are unchanged, so nothing meaningful changed for users here. ---- 6 / 22 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/k/ksh93u+m/ksh93u+m_1.0.10.orig.tar.gz Result: main ksh-1.0.10/src/lib/libast/misc/fastfind.c:953:22: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: The PR does not change whether this LHS warning is reported. It only attaches an error path. At line 953 `d` can really be negative: the else branch runs when `d < -127` or `d > 127`, so `d >> 8` on a negative int is a valid portability finding. The 'your' version keeps the same warning and severity and adds notes pointing to the condition `d>=-127`. That explains why the value is negative, so the message is more informative. ---- 7 / 22 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/k/ksh93u+m/ksh93u+m_1.0.10.orig.tar.gz Result: your ksh-1.0.10/src/lib/libast/misc/fastfind.c:1142:19: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] ksh-1.0.10/src/lib/libast/misc/fastfind.c:1139:10: note: Assuming that condition 'z<0' is not redundant ksh-1.0.10/src/lib/libast/misc/fastfind.c:1142:19: note: Shifting a negative value is technically undefined behaviour Explanation: The PR only adds an error path to the warning. The warning text, location and severity stay the same (still portability, shiftNegativeLHS). z comes from strtol and the branch handles z<0, so a right shift of a negative value is possible. The new note 'Assuming that condition z<0 is not redundant' correctly explains where the negative value comes from. The message is more informative and no less accurate. ---- 8 / 22 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/k/ksh93u+m/ksh93u+m_1.0.10.orig.tar.gz Result: your ksh-1.0.10/src/lib/libast/misc/fastfind.c:1143:19: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] ksh-1.0.10/src/lib/libast/misc/fastfind.c:1139:10: note: Assuming that condition 'z<0' is not redundant ksh-1.0.10/src/lib/libast/misc/fastfind.c:1143:19: note: Shifting a negative value is technically undefined behaviour Explanation: The warning itself is unchanged. It is the same shiftNegativeLHS portability warning on 'z >> 16', inside the branch guarded by 'z < 0 || ...', so z can be negative and the warning is valid. The PR only adds an error path that points to the 'z<0' condition as the reason z can be negative. That makes the warning easier to understand, and the severity for LHS stays portability. ---- 9 / 22 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/k/ksh93u+m/ksh93u+m_1.0.10.orig.tar.gz Result: your ksh-1.0.10/src/lib/libast/misc/fastfind.c:1144:19: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] ksh-1.0.10/src/lib/libast/misc/fastfind.c:1139:10: note: Assuming that condition 'z<0' is not redundant ksh-1.0.10/src/lib/libast/misc/fastfind.c:1144:19: note: Shifting a negative value is technically undefined behaviour Explanation: The warning itself is unchanged: same location, same severity (portability) and same id. The PR only adds an error path. Here z comes from strtol and is checked with 'z < 0 || ...', so z can be negative inside the branch, and 'z >> 8' then right-shifts a negative signed value. The new note 'Assuming that condition 'z<0' is not redundant' correctly explains where the negative value comes from. The warning was already reported, and the added note makes it easier to understand. ---- 10 / 22 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/k/ksh93u+m/ksh93u+m_1.0.10.orig.tar.gz Result: your ksh-1.0.10/src/lib/libast/misc/fastfind.c:953:22: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] ksh-1.0.10/src/lib/libast/misc/fastfind.c:948:9: note: Assuming that condition 'd>=-127' is not redundant ksh-1.0.10/src/lib/libast/misc/fastfind.c:953:22: note: Shifting a negative value is technically undefined behaviour Explanation: The same shiftNegativeLHS portability warning was reported before the PR, with the same location and severity. The PR only adds an error path. The note correctly explains where the negative value comes from: line 953 is in the else branch of `if (d >= -127 && d <= 127)`, so d can be below -127, and `d >> 8` then shifts a negative value. The finding itself is unchanged (for `>>` it is really implementation-defined rather than undefined), but the extra note makes the report easier to understand and check. ---- 11 / 22 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsdl1.2/libsdl1.2_1.2.15+dfsg2.orig.tar.gz Result: main SDL-1.2.15/src/audio/SDL_mixer.c:219:16: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: The removed 'main' line comes back unchanged as a 'your' line: same location, id, severity (portability) and text. The only difference is the new error-path notes showing how dst_sample becomes -32768. The finding is the same in both versions. Arguably it is inaccurate either way, since `>>=` on a negative int is implementation-defined in C, not undefined. The PR only adds diagnostic context, which does not change what users are warned about. ---- 12 / 22 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsdl1.2/libsdl1.2_1.2.15+dfsg2.orig.tar.gz Result: main SDL-1.2.15/src/audio/SDL_mixer.c:251:16: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: The removed main line is not really gone. It comes back as the matching 'your' line with the same location, severity, id and text. The only difference is the new error path (dst_sample = min_audioval = -32768, then `dst_sample >>= 8`), which is correct and gives the user context. Whether the warning is right does not change: it is a right shift of a possibly negative signed int. Strictly, that is implementation-defined rather than undefined, but the PR does not touch this. Users see essentially the same finding with extra notes, so the effect is neutral to slightly positive. ---- 13 / 22 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsdl1.2/libsdl1.2_1.2.15+dfsg2.orig.tar.gz Result: main SDL-1.2.15/src/audio/dc/aica.c:132:18: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: The warning is unchanged in id, severity and location; the PR only attaches an error path to it. It is a true positive: freq_hi starts at 7 and the loops can decrement it down to -8, so `freq_hi << 11` shifts a negative signed int, which is undefined in C. The new note ('Assuming that condition freq_hi>-8 is not redundant') points at the loop that makes the value negative, so the message is more informative. ---- 14 / 22 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsdl1.2/libsdl1.2_1.2.15+dfsg2.orig.tar.gz Result: your SDL-1.2.15/src/audio/SDL_mixer.c:219:16: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] SDL-1.2.15/src/audio/SDL_mixer.c:216:19: note: Assignment 'dst_sample=min_audioval', assigned value is -32768 SDL-1.2.15/src/audio/SDL_mixer.c:215:21: note: Assuming condition is true SDL-1.2.15/src/audio/SDL_mixer.c:212:21: note: Assuming condition is false SDL-1.2.15/src/audio/SDL_mixer.c:219:16: note: Shifting a negative value is technically undefined behaviour Explanation: Same shiftNegativeLHS warning at the same location, with the same severity and message. The only difference is the added error path notes. They correctly show how dst_sample becomes -32768 (assigned min_audioval when the sample is below the minimum) before 'dst_sample >>= 8'. Right-shifting a negative signed value is implementation-defined rather than undefined, but that is the same in main, so the warning itself did not change. The added notes make the existing warning easier to understand. ---- 15 / 22 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsdl1.2/libsdl1.2_1.2.15+dfsg2.orig.tar.gz Result: your SDL-1.2.15/src/audio/SDL_mixer.c:251:16: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] SDL-1.2.15/src/audio/SDL_mixer.c:248:19: note: Assignment 'dst_sample=min_audioval', assigned value is -32768 SDL-1.2.15/src/audio/SDL_mixer.c:247:21: note: Assuming condition is true SDL-1.2.15/src/audio/SDL_mixer.c:244:21: note: Assuming condition is false SDL-1.2.15/src/audio/SDL_mixer.c:251:16: note: Shifting a negative value is technically undefined behaviour Explanation: Main already reported this shiftNegativeLHS warning at line 251; the PR only adds an error path. The notes are correct: line 248 assigns min_audioval (-32768) when the line 247 condition is true and the line 244 condition is false, so `dst_sample >>= 8` shifts a negative value. Severity and ID are unchanged. Whether a right shift of a negative value deserves this warning is debatable, since it is implementation-defined rather than undefined, but that predates the PR. The added trace makes the existing warning easier to understand, a small usability gain. ---- 16 / 22 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsdl1.2/libsdl1.2_1.2.15+dfsg2.orig.tar.gz Result: your SDL-1.2.15/src/audio/dc/aica.c:132:18: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] SDL-1.2.15/src/audio/dc/aica.c:127:37: note: Assuming that condition 'freq_hi>-8' is not redundant SDL-1.2.15/src/audio/dc/aica.c:132:18: note: Shifting a negative value is technically undefined behaviour Explanation: The PR only adds an error path to the existing shiftNegativeLHS portability warning. The warning itself is unchanged. In AICA_FREQ, freq_hi starts at 7 and is decremented while freq < freq_base and freq_hi > -8, so it can reach negative values down to -8. `freq_hi << 11` then left-shifts a negative signed int, which is UB in C. The warning is a true positive, and the new note pointing at the loop condition 'freq_hi>-8' tells the user where the negative value comes from, so the message is more useful. ---- 17 / 22 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/python-msgspec/python-msgspec_0.21.1.orig.tar.gz Result: main python-msgspec-0.21.1/src/msgspec/_core.c:12535:21: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: This 'main' line is half of a pair. The same shiftNegativeLHS warning, with the same location, severity and text, is still reported by 'your'. The only difference is the new error-path notes. In the source, x is negative inside the `x < -(1LL<<31)` branch, so the diagnosis is the same before and after. Whether the warning is valid does not change. The added note ('Assuming that condition ... is not redundant') adds little for users, so the change does not matter either way. ---- 18 / 22 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/python-msgspec/python-msgspec_0.21.1.orig.tar.gz Result: main python-msgspec-0.21.1/src/msgspec/_core.c:12540:21: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: The removed main line comes back unchanged as a 'your' line: same location, same message, same portability severity. The only difference is the added error-path notes. The PR changes only how the message is reported, not whether it is reported. In this branch x is always negative (x < -(1<<15)), so the shiftNegativeLHS warning inside _msgspec_store32 is as valid as before. The new note ('Assuming that condition x<-(1LL<<31) is not redundant') adds little: x is negative here regardless of that condition. Overall the user-visible result is essentially the same. ---- 19 / 22 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/python-msgspec/python-msgspec_0.21.1.orig.tar.gz Result: main python-msgspec-0.21.1/src/msgspec/_core.c:12547:21: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: This 'main' line is not really removed. The same shiftNegativeLHS warning at 12547:21 is reported again by 'your', with identical text and severity (portability for LHS). The only difference is that the PR now attaches an error path. Its note says x<-(1<<7) is assumed not redundant, which fits the code: x is negative in this branch (int16_t)x and is shifted inside _msgspec_store16. Whether the warning is a true or false positive is unchanged. The added note is a minor cosmetic change rather than a real gain or loss. ---- 20 / 22 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/python-msgspec/python-msgspec_0.21.1.orig.tar.gz Result: your python-msgspec-0.21.1/src/msgspec/_core.c:12535:21: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] python-msgspec-0.21.1/src/msgspec/_core.c:12532:22: note: Assuming that condition 'x<-(1LL<<31)' is not redundant python-msgspec-0.21.1/src/msgspec/_core.c:12535:21: note: Shifting a negative value is technically undefined behaviour Explanation: Only the notes changed. The shiftNegativeLHS warning at line 12535 keeps the same location, severity and text; it now carries an error path. Inside the `x < -(1LL<<31)` branch, `x` is negative, and `_msgspec_store64` shifts it. The new note points to the condition at line 12532 as the reason `x` is negative, which helps the user see why it is reported. The wording 'Assuming that condition ... is not redundant' is slightly odd, since `x` is always negative in that branch, but the path is correct. The warning is portability-level and existed before either way. Whether the macro's shift is truly UB or only implementation-defined is not visible here, so the warning's validity is unchanged by this PR. ---- 21 / 22 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/p/python-msgspec/python-msgspec_0.21.1.orig.tar.gz Result: your python-msgspec-0.21.1/src/msgspec/_core.c:12540:21: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] python-msgspec-0.21.1/src/msgspec/_core.c:12532:22: note: Assuming that condition 'x<-(1LL<<31)' is not redundant python-msgspec-0.21.1/src/msgspec/_core.c:12540:21: note: Shifting a negative value is technically undefined behaviour Explanation: The shiftNegativeLHS warning at line 12540 was already reported by main with the same severity and text. The PR only adds an error path to it. In this else branch x is between -(2^31) and -(2^15)-1, so it is always negative, and the note pointing at the condition 'x<-(1LL<<31)' (line 12532) shows where Cppcheck got the negative value. That gives the user extra context without changing what is reported. Whether the warning itself is valid depends on how _msgspec_store32 shifts its argument, which is not shown. A right shift of a negative value is implementation-defined rather than undefined. Either way, the warning's status is unchanged by this PR. ---- 22 / 22 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/python-msgspec/python-msgspec_0.21.1.orig.tar.gz Result: your python-msgspec-0.21.1/src/msgspec/_core.c:12547:21: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] python-msgspec-0.21.1/src/msgspec/_core.c:12544:22: note: Assuming that condition 'x<-(1<<7)' is not redundant python-msgspec-0.21.1/src/msgspec/_core.c:12547:21: note: Shifting a negative value is technically undefined behaviour Explanation: Main already reported this shiftNegativeLHS warning. The PR only attaches an error path. The new note correctly explains why the shifted value is negative: inside the `x < -(1<<7)` branch, `x` is below -128, so `(int16_t)x` passed to the `_msgspec_store16` byte-store macro is negative. Severity, id and text are unchanged; the user just gets better context. Whether the warning itself is fully justified depends on the macro body, which is not shown. If the macro only right-shifts, that is implementation-defined rather than undefined, but that is unchanged by this PR.