AI review of 2026-10-26_20-17-43-9df444721ac5-results.txt PR: #8967 https://github.com/cppcheck-opensource/cppcheck/pull/8967 Tested: 9df444721ac586062897f63dece92c2aae33ca17 Merge base: 275f16a5223230cdcadf3f3f92bf9716138ac4fc Reviewed: 2026-10-28 07:38:20 UTC Model: claude-opus-5-5 (effort high) Results: 19 reviewed of 19 in the report Verdicts: 19 regression Tokens: 39642 input, 52794 cache read, 2933 cache write, 16349 output The verdicts are written by AI and can be wrong. ---- 1 / 19 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/aria2/aria2_1.37.0+debian.orig.tar.gz Result: main aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:70:12: style: Condition 'wlen<=len' is always true [knownConditionTrueFalse] aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:67:47: note: Assignment 'wlen=df->feedseq[df->seqidx]>len?len:df->feedseq[df->seqidx]', assigned value is less than symbolic=len+1 aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:70:12: note: Condition 'wlen<=len' is always true Explanation: `wlen` is `min(feedseq, len)`: when `feedseq > len` it gets `len`, otherwise it gets `feedseq`, which is `<= len`. So `wlen <= len` is always true, and the warning is a true positive. The `else` branch is dead code. The PR turned the `?` handling in `valueFlowImpossibleValues` into an `else if`. The preceding branch (most likely the unsigned impossible-value one) now matches the unsigned `size_t` ternary first, so the symbolic `< len+1` value is never set and the warning is lost. ---- 2 / 19 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/aria2/aria2_1.37.0+debian.orig.tar.gz Result: main aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:88:12: style: Condition 'wlen<=len' is always true [knownConditionTrueFalse] aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:85:47: note: Assignment 'wlen=df->feedseq[df->seqidx]>len?len:df->feedseq[df->seqidx]', assigned value is less than symbolic=len+1 aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:88:12: note: Condition 'wlen<=len' is always true Explanation: On line 85, `wlen` is set to `feedseq > len ? len : feedseq`, which is min(feedseq, len). So `wlen <= len` on line 88 is always true. The warning was a genuine true positive, and it points at a real logic slip: the else branch is dead code, and `<` was probably intended. The PR turned the `?` handling in valueFlowImpossibleValues from `if` into `else if`, chaining it to the preceding block. That appears to stop the impossible-value/symbolic bound being set for this ternary, so the correct warning is lost. ---- 3 / 19 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/aria2/aria2_1.37.0+debian.orig.tar.gz Result: main aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:67:12: style: Condition 'wlen<=len' is always true [knownConditionTrueFalse] aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:64:47: note: Assignment 'wlen=df->feedseq[df->seqidx]>len?len:df->feedseq[df->seqidx]', assigned value is less than symbolic=len+1 aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:67:12: note: Condition 'wlen<=len' is always true Explanation: `wlen` is assigned `feedseq > len ? len : feedseq`, so `wlen <= len` is always true. The warning is a true positive. The PR turned the `?` handling in valueFlowImpossibleValues into an `else if`. For an unsigned (`size_t`) ternary, the preceding unsigned-minimum branch already matches, so the symbolic bound from the `?` branch is no longer set. The `|` handling the PR adds is unrelated to this code. Losing this correct warning is a regression. ---- 4 / 19 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/aria2/aria2_1.37.0+debian.orig.tar.gz Result: main aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:81:12: style: Condition 'wlen<=len' is always true [knownConditionTrueFalse] aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:78:47: note: Assignment 'wlen=df->feedseq[df->seqidx]>len?len:df->feedseq[df->seqidx]', assigned value is less than symbolic=len+1 aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:81:12: note: Condition 'wlen<=len' is always true Explanation: `wlen` is computed as `feedseq > len ? len : feedseq`, which is min(feedseq, len). So `wlen <= len` really is always true, and the removed warning was a true positive (the else branch is dead code). The PR turned the `?` handling in valueFlowImpossibleValues into an `else if`. The preceding block most likely handles unsigned expressions (it sets an impossible lower bound), and this ternary is `size_t`. So that block now consumes the token and the ternary's symbolic impossible value (`len+1`) is no longer set. As a result the valid knownConditionTrueFalse warning is lost. ---- 5 / 19 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/clearsilver/clearsilver_0.10.5.orig.tar.gz Result: main clearsilver-0.10.5/util/dict.c:264:23: style: Condition 'hash!=(unsigned int)-1' is always true [knownConditionTrueFalse] clearsilver-0.10.5/util/dict.c:261:25: note: Assignment 'hash=dict->hash(id)%65536', assigned value is less than 65536 clearsilver-0.10.5/util/dict.c:264:23: note: Condition 'hash!=(unsigned int)-1' is always true Explanation: `hash = dict->hash(id) % DICT_HASH_BITS` (65536) stores a value below 65536 in an unsigned 32-bit variable. So `hash != (UINT32)-1` (0xFFFFFFFF) really is always true, and the removed warning was a true positive. The PR only meant to add impossible-0 values for `|`. It also rewrote the `%` branch and turned an `if` into `else if`, and this unintended change lost a correct knownConditionTrueFalse warning. The exact cause is unclear, but losing a correct warning is a regression. ---- 6 / 19 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/d/dino-im/dino-im_0.5.1+git20260802.baea516.orig.tar.xz Result: main dino-im-0.5.1+git20260802.baea516/plugins/omemo/src/native/helper.c:191:25: style: Condition 'pad_len==0' is always false [knownConditionTrueFalse] dino-im-0.5.1+git20260802.baea516/plugins/omemo/src/native/helper.c:190:26: note: Assignment 'pad_len=16-(plaintext_len%16)', assigned value is greater than 0 dino-im-0.5.1+git20260802.baea516/plugins/omemo/src/native/helper.c:191:25: note: Condition 'pad_len==0' is always false Explanation: `plaintext_len % 16` is in [0,15], so `pad_len = 16 - (plaintext_len % 16)` is in [1,16] and fits in uint8_t. `pad_len == 0` can never be true, so main's warning was a true positive; the check is dead defensive code. The PR changed `if` to `else if`, which joins the `%` branch to the earlier if-chain. A `%` token that matches the earlier branch (likely the unsigned/size_t case) no longer gets the impossible lower-bound value, so this true positive is lost. ---- 7 / 19 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/k/kannel/kannel_1.4.5.orig.tar.gz Result: main gateway-1.4.5/test/drive_smpp.c:284:37: style: Condition '(id%enquire_interval)==0' is always true [knownConditionTrueFalse] Explanation: Main reported `(id % enquire_interval) == 0` as always true. For that, Cppcheck must have known `enquire_interval` as a constant, most plausibly 1, since only then is an unsigned `id % n` always 0. The definition of `enquire_interval` is not shown, so this is an inference. The PR is meant to add impossible values for `|`, but it also turned the `?` handling into an `else if` and rewrote the `%` match. Losing this warning looks like a side effect of that restructuring, not a fix for a false positive. If `enquire_interval` really is never changed from 1, the removed warning was a true positive, so this is likely a regression. ---- 8 / 19 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libe/libevtx/libevtx_20251118.orig.tar.gz Result: main libevtx-20251118/libuna/libuna_base64_stream.c:2423:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse] libevtx-20251118/libuna/libuna_base64_stream.c:2419:27: note: Assuming that condition 'remaining_size==1' is not redundant libevtx-20251118/libuna/libuna_base64_stream.c:2411:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3 libevtx-20251118/libuna/libuna_base64_stream.c:2413:21: note: Assuming condition is true libevtx-20251118/libuna/libuna_base64_stream.c:2423:27: note: Condition 'remaining_size==2' is always true Explanation: `remaining_size = byte_stream_size % 3` can only be 0, 1 or 2. Inside `if (remaining_size != 0)`, once `remaining_size == 1` is false, `remaining_size == 2` must be true, so the removed warning was a true positive (the else-if is redundant). The PR turned the `?`/`%` handling into an `else if` attached to the earlier branch in valueFlowImpossibleValues. That earlier branch most likely handles unsigned expressions, and the `size_t % 3` result is unsigned. If so, the `%` branch is now skipped and the impossible 'value >= 3' bound is never set, so the correct warning is lost. The same happens at line 2672. ---- 9 / 19 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libe/libevtx/libevtx_20251118.orig.tar.gz Result: main libevtx-20251118/libuna/libuna_base64_stream.c:2672:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse] libevtx-20251118/libuna/libuna_base64_stream.c:2668:27: note: Assuming that condition 'remaining_size==1' is not redundant libevtx-20251118/libuna/libuna_base64_stream.c:2660:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3 libevtx-20251118/libuna/libuna_base64_stream.c:2662:21: note: Assuming condition is true libevtx-20251118/libuna/libuna_base64_stream.c:2672:27: note: Condition 'remaining_size==2' is always true Explanation: `remaining_size = byte_stream_size % 3` is in [0,2]. Inside `if (remaining_size != 0)`, after `else if (remaining_size == 1)`, the check `remaining_size == 2` is always true. The warning that main reported is therefore a true positive. Its loss looks like a side effect of the PR changing the `?` branch into an `else if` chained to the previous `if` in valueFlowImpossibleValues. That change alters which branch handles the `%` token, so the impossible-value bound on the `%` result is no longer set. Losing a correct knownConditionTrueFalse warning is a regression. ---- 10 / 19 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/libf/libfsfat/libfsfat_0~20260208.orig.tar.gz Result: main libfsfat-20260208/libuna/libuna_base64_stream.c:2423:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse] libfsfat-20260208/libuna/libuna_base64_stream.c:2419:27: note: Assuming that condition 'remaining_size==1' is not redundant libfsfat-20260208/libuna/libuna_base64_stream.c:2411:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3 libfsfat-20260208/libuna/libuna_base64_stream.c:2413:21: note: Assuming condition is true libfsfat-20260208/libuna/libuna_base64_stream.c:2423:27: note: Condition 'remaining_size==2' is always true Explanation: `remaining_size = byte_stream_size % 3` can only be 0, 1 or 2. Inside `remaining_size != 0` and after the `remaining_size == 1` branch, `remaining_size == 2` really is always true, so the removed warning was a true positive. The PR changed `if` to `else if` before the `?`/`%` handling in valueFlowImpossibleValues. The earlier branch (likely the unsigned non-negative impossible value) now prevents the `%` upper-bound impossible value from being set for this size_t expression. That logic change, not better understanding of the code, is why the warning was lost. ---- 11 / 19 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/libf/libfsfat/libfsfat_0~20260208.orig.tar.gz Result: main libfsfat-20260208/libuna/libuna_base64_stream.c:2672:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse] libfsfat-20260208/libuna/libuna_base64_stream.c:2668:27: note: Assuming that condition 'remaining_size==1' is not redundant libfsfat-20260208/libuna/libuna_base64_stream.c:2660:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3 libfsfat-20260208/libuna/libuna_base64_stream.c:2662:21: note: Assuming condition is true libfsfat-20260208/libuna/libuna_base64_stream.c:2672:27: note: Condition 'remaining_size==2' is always true Explanation: `remaining_size = byte_stream_size % 3` is always 0, 1 or 2. Inside `if (remaining_size != 0)`, once `== 1` has been ruled out, `remaining_size == 2` really is always true, so the warning is a true positive (a redundant check). The PR changed the `if` for the `?` case to `else if`. That ties the `?` / `%` / `|` branches to the preceding unsigned-value branch in valueFlowImpossibleValues. For an unsigned expression such as `size_t % 3`, the unsigned branch now runs and the `%` branch (impossible value >= 3) is skipped. The upper bound is lost and the true positive disappears, which is an unintended side effect of the change. ---- 12 / 19 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libo/libolecf/libolecf_20240427.orig.tar.gz Result: main libolecf-20240427/libuna/libuna_base64_stream.c:2423:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse] libolecf-20240427/libuna/libuna_base64_stream.c:2419:27: note: Assuming that condition 'remaining_size==1' is not redundant libolecf-20240427/libuna/libuna_base64_stream.c:2411:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3 libolecf-20240427/libuna/libuna_base64_stream.c:2413:21: note: Assuming condition is true libolecf-20240427/libuna/libuna_base64_stream.c:2423:27: note: Condition 'remaining_size==2' is always true Explanation: `remaining_size = byte_stream_size % 3` can only be 0, 1 or 2. Inside `if (remaining_size != 0)`, once `remaining_size == 1` has failed, `remaining_size == 2` must be true. So the removed knownConditionTrueFalse warning was a correct true positive. The PR changed the `?` handling from `if` to `else if`, which pulls the `%` branch into the earlier if/else chain. When the earlier branch matches the `%` token, the impossible-value bound of 3 is no longer set. The earlier branch is not shown, but it is plausibly the unsigned-type handling, since `byte_stream_size` is a `size_t`. That loses a valid diagnostic, which is a regression unrelated to the PR's intent. ---- 13 / 19 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libo/libolecf/libolecf_20240427.orig.tar.gz Result: main libolecf-20240427/libuna/libuna_base64_stream.c:2672:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse] libolecf-20240427/libuna/libuna_base64_stream.c:2668:27: note: Assuming that condition 'remaining_size==1' is not redundant libolecf-20240427/libuna/libuna_base64_stream.c:2660:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3 libolecf-20240427/libuna/libuna_base64_stream.c:2662:21: note: Assuming condition is true libolecf-20240427/libuna/libuna_base64_stream.c:2672:27: note: Condition 'remaining_size==2' is always true Explanation: `remaining_size = byte_stream_size % 3` can only be 0, 1 or 2. Inside `if (remaining_size != 0)`, after the `remaining_size == 1` branch, `remaining_size == 2` really is always true, so main's warning is a true positive (redundant style condition). The note 'assigned value is less than 3' shows main relied on the impossible >=3 bound set for `%`. The PR turned the `?`/`%` handling into an `else if` chain after the preceding `if`. When that earlier branch matches the `%` token (likely because the operands are unsigned `size_t`), the `%` bound is no longer set. That fits the loss of this correct warning, so dropping it is a regression. ---- 14 / 19 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/mupen64plus-video-rice/mupen64plus-video-rice_2.6.0.orig.tar.gz Result: main mupen64plus-video-rice-src-2.6.0/src/TextureFilters.cpp:383:34: style: Condition 'z%1' is always false [knownConditionTrueFalse] Explanation: `z` is `uint32`, so `z%1` is always 0 and the ternary condition is always false. The removed warning was a true positive, and it points at a real bug: the author probably meant `z%2`. The PR turned the `?` branch into an `else if`, which chains it to the preceding unsigned-token `if` in `valueFlowImpossibleValues`. For unsigned expressions the `%` branch no longer runs, so the impossible `>=1` bound is never set on `z%1`. Combined with the unsigned `>=0` bound, that bound was what let Cppcheck prove the value is 0. The PR therefore lost a true positive through an unintended side effect. ---- 15 / 19 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mygui/mygui_3.4.4+dfsg.orig.tar.xz Result: main MyGUI-mygui-84c2874/UnitTests/UnitTest_MultiList/UnitTest_List.h:161:19: style: Condition 'index==3' is always true [knownConditionTrueFalse] MyGUI-mygui-84c2874/UnitTests/UnitTest_MultiList/UnitTest_List.h:159:19: note: Assuming that condition 'index==2' is not redundant MyGUI-mygui-84c2874/UnitTests/UnitTest_MultiList/UnitTest_List.h:152:34: note: Assignment 'index=(unsigned long)rand()%4', assigned value is less than 4 MyGUI-mygui-84c2874/UnitTests/UnitTest_MultiList/UnitTest_List.h:161:19: note: Condition 'index==3' is always true Explanation: `index = (size_t)rand() % 4` can only be 0..3. After the checks for 0, 1 and 2, `index == 3` really is always true, so the removed warning was a true positive (even if the explicit check is a readable style choice). The PR turned the separate `if` into `else if`. For an unsigned `%` expression, the earlier branch (likely the one that marks values below 0 as impossible for unsigned types) now runs instead of the `%` branch. So the 'value is less than 4' bound is no longer set, and Cppcheck lost information. This is an unintended side effect, not a fixed false positive. ---- 16 / 19 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/n/nng/nng_1.12.4.orig.tar.gz Result: main nng-1.12.4/tests/multistress.c:767:5: style: Condition 'x>i' is always false [knownConditionTrueFalse] nng-1.12.4/tests/multistress.c:767:5: note: Assignment 'x=rand()%(sizeof(templates)/sizeof(templates[0]))', assigned value is less than 3 nng-1.12.4/tests/multistress.c:767:5: note: Assuming that condition 'i>1' is not redundant nng-1.12.4/tests/multistress.c:767:5: note: Condition 'x>i' is always false Explanation: `x = rand() % NTEMPLATES` with NTEMPLATES == 3 gives x <= 2, and the loop condition `while (i > 1)` gives i >= 2, so `x > i` really is always false. The removed warning was a true positive (the check is dead defensive code). The likely cause is that the PR turned the `?` branch into an `else if`. The `%` lower-bound impossible value can now be skipped when an earlier branch in valueFlowImpossibleValues matches the same token. Cppcheck lost knowledge it had before. ---- 17 / 19 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/n/nng/nng_1.12.4.orig.tar.gz Result: main nng-1.12.4/tests/reqstress.c:267:5: style: Condition 'x>i' is always false [knownConditionTrueFalse] nng-1.12.4/tests/reqstress.c:267:5: note: Assignment 'x=rand()%(sizeof(templates)/sizeof(templates[0]))', assigned value is less than 3 nng-1.12.4/tests/reqstress.c:267:5: note: Assuming that condition 'i>1' is not redundant nng-1.12.4/tests/reqstress.c:267:5: note: Condition 'x>i' is always false Explanation: `x = rand() % NTEMPLATES` with NTEMPLATES == 3 gives x in [0,2]. Inside `while (i > 1)`, i is at least 2, so `x > i` can never be true. The condition is genuinely always false, so the removed warning was a true positive. The PR turned the `?` handling into an `else if`, which joins it to the preceding `if` in valueFlowImpossibleValues. If that earlier branch matches a `%` token, the `%` bound is no longer set, which would explain why the warning disappeared. Losing it is a regression. ---- 18 / 19 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/openjpeg2/openjpeg2_2.5.4.orig.tar.xz Result: main openjpeg-2.5.4/src/lib/openjp2/t1.c:1527:30: style: Condition 'h%4==3' is always true [knownConditionTrueFalse] openjpeg-2.5.4/src/lib/openjp2/t1.c:1525:30: note: Assuming that condition 'h%4==2' is not redundant openjpeg-2.5.4/src/lib/openjp2/t1.c:1527:30: note: Condition 'h%4==3' is always true Explanation: `h` is unsigned. Inside `if (h % 4)`, the value is non-zero, and the branches have already ruled out 1 and 2, so `h % 4 == 3` really is always true. The removed warning was a true positive. The likely cause is the PR's change of `if` to `else if` in valueFlowImpossibleValues. Unsigned expressions (such as `h % 4`) are presumably caught by the earlier unsigned branch. They then no longer reach the `%` branch, so they lose the impossible upper bound (value >= 4 is impossible) that let Cppcheck prove the condition. This is an unintended loss of precision. ---- 19 / 19 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/q/qt6-3d/qt6-3d_6.11.2+dfsg.orig.tar.xz Result: main qt3d-everywhere-src-6.11.2/src/3rdparty/assimp/src/code/AssetLib/FBX/FBXUtil.cpp:217:20: style: Condition 'extraBytes>0' is always true [knownConditionTrueFalse] qt3d-everywhere-src-6.11.2/src/3rdparty/assimp/src/code/AssetLib/FBX/FBXUtil.cpp:199:27: note: Assignment 'extraBytes=3-length%3', assigned value is greater than 0 qt3d-everywhere-src-6.11.2/src/3rdparty/assimp/src/code/AssetLib/FBX/FBXUtil.cpp:217:20: note: Condition 'extraBytes>0' is always true Explanation: `length % 3` is in [0,2], so `extraBytes = 3 - length % 3` is always in [1,3], and `extraBytes > 0` is always true. The warning was a true positive, and it also points at a real logic issue: when length is a multiple of 3, extraBytes is 3, not 0. The PR changed the separate `if` before the `?` branch into an `else if`. As a result, the `%` lower-bound impossible value is no longer set for tokens that already matched the first branch, most likely because the operands are unsigned. Losing that value caused the true positive to disappear.