AI review of 2026-10-05_14-08-13-8502e53e61e8-results.txt
PR:          #8819 https://github.com/cppcheck-opensource/cppcheck/pull/8819
Tested:      8502e53e61e8a51378a7db4cbedce3fb6a9d8b00
Merge base:  43425eec4b62c4245f77a055322f6725593e3a7d
Reviewed:    2026-10-06 10:55:27 UTC
Model:       claude-opus-5-5 (effort high)
Results:     18 reviewed of 18 in the report
Verdicts:    5 improvement, 1 neutral, 12 regression
Tokens:      52843 input, 128520 cache read, 7560 cache write, 6571 output

The verdicts are written by AI and can be wrong.

---- 1 / 18 ----
Verdict:     IMPROVEMENT (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/f/ffmpeg/ffmpeg_9.0.2.orig.tar.xz
Result:      main ffmpeg-9.0.2/libavcodec/wavpackenc.c:2123:18: style: Condition 'code<extras' is always false [knownConditionTrueFalse]
     ffmpeg-9.0.2/libavcodec/wavpackenc.c:2120:24: note: Assuming condition 'maxcode' is false
     ffmpeg-9.0.2/libavcodec/wavpackenc.c:2120:24: note: Assignment 'bitcount=(maxcode)?32-ff_clz(maxcode):0', assigned value is 0
     ffmpeg-9.0.2/libavcodec/wavpackenc.c:2121:53: note: Assignment 'extras=(1<<bitcount)-maxcode-1', assigned value is less than 1
     ffmpeg-9.0.2/libavcodec/wavpackenc.c:2123:18: note: Condition 'code<extras' is always false
Explanation: `extras = (1 << bitcount) - maxcode - 1` is unsigned and is normally positive. For example, maxcode=5 gives bitcount=3 and extras=2, so `code < extras` can be true. Main's reasoning took an impossible-bound value ("less than 1") through unsigned subtraction, where wrap-around invalidates the bound, and reported a false 'always false'. The PR stops passing impossible bounds through unsigned +/-/*, so this false positive goes away.

---- 2 / 18 ----
Verdict:     REGRESSION (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/f/ffmpeg/ffmpeg_9.0.2.orig.tar.xz
Result:      your ffmpeg-9.0.2/libavcodec/dca_core.c:0:0: debug: ValueFlow maximum iterations exceeded [valueFlowMaxIterations]
Explanation: This is a new debug message that main did not produce. The PR adds impossible lower and upper bound values to every integral cast token. dca_core.c contains many casts in its DSP arithmetic, so the extra values plausibly keep ValueFlow changing until it hits the iteration limit. When that limit is reached, the analysis of this file stops before it is complete, so some values may be missing later. The same message also appears for dca_xll.c and dcadsp.c, which points to a systematic cost of the change rather than a one-off. No new true positive comes with it.

---- 3 / 18 ----
Verdict:     REGRESSION (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/f/ffmpeg/ffmpeg_9.0.2.orig.tar.xz
Result:      your ffmpeg-9.0.2/libavcodec/dca_xll.c:0:0: debug: ValueFlow maximum iterations exceeded [valueFlowMaxIterations]
Explanation: The PR adds impossible-bound values to every integral cast. dca_xll.c has many casts in tight loops, so ValueFlow now hits its maximum iteration limit there. The new valueFlowMaxIterations debug message means analysis is cut short and may be less complete for this file. It shows extra cost or reduced analysis, not better understanding of the code.

---- 4 / 18 ----
Verdict:     REGRESSION (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/f/ffmpeg/ffmpeg_9.0.2.orig.tar.xz
Result:      your ffmpeg-9.0.2/libavcodec/dcadsp.c:0:0: debug: ValueFlow maximum iterations exceeded [valueFlowMaxIterations]
Explanation: The PR now adds impossible lower/upper bound values to every integral cast token. dcadsp.c is DSP code with many integer casts in arithmetic, so this plausibly creates extra values that keep changing between ValueFlow passes. As a result, ValueFlow no longer converges within the iteration limit for this file. The new valueFlowMaxIterations debug message means the analysis is cut off and less complete than before, which counts as a regression. The same message also appears for two other dca files.

---- 5 / 18 ----
Verdict:     IMPROVEMENT (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/g/gtkwave/gtkwave_3.3.127.orig.tar.gz
Result:      your gtkwave-gtk3-3.3.127/src/helpers/lxt2_write.c:1603:29: error: Shifting signed 32-bit value by 31 bits is undefined behaviour [shiftTooManyBitsSigned]
     gtkwave-gtk3-3.3.127/src/helpers/lxt2_write.c:1597:16: note: Assignment 'len=32', assigned value is 32
     gtkwave-gtk3-3.3.127/src/helpers/lxt2_write.c:1597:7: note: Assuming condition is true
     gtkwave-gtk3-3.3.127/src/helpers/lxt2_write.c:1599:1: note: len is decremented', new value is 31
     gtkwave-gtk3-3.3.127/src/helpers/lxt2_write.c:1601:7: note: Assignment 'i=0', assigned value is 0
     gtkwave-gtk3-3.3.127/src/helpers/lxt2_write.c:1603:29: note: Shift
Explanation: In `lxt2_wr_expand_integer_to_bits`, `len` is clamped to 32 and then decremented to 31. On the first iteration (`i=0`) the code evaluates `1<<(len-i)`, which is `1<<31`. The literal `1` is a signed 32-bit int, so in C this shift overflows `int` and is undefined behaviour. This is a C file, so the newly reported `shiftTooManyBitsSigned` is a true positive. The path shown in the notes (len>32 → len=32 → 31 → shift by 31) is real, since `s->len` can be 32 or more. The same pattern in `vzt_write.c` is also correct. Confidence is medium rather than high: the PR adds impossible bounds on casts and limits propagation through unsigned arithmetic, and it is not obvious which part of that newly exposed this path.

---- 6 / 18 ----
Verdict:     IMPROVEMENT (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/g/gtkwave/gtkwave_3.3.127.orig.tar.gz
Result:      your gtkwave-gtk3-3.3.127/src/helpers/vzt_write.c:1593:29: error: Shifting signed 32-bit value by 31 bits is undefined behaviour [shiftTooManyBitsSigned]
     gtkwave-gtk3-3.3.127/src/helpers/vzt_write.c:1587:16: note: Assignment 'len=32', assigned value is 32
     gtkwave-gtk3-3.3.127/src/helpers/vzt_write.c:1587:7: note: Assuming condition is true
     gtkwave-gtk3-3.3.127/src/helpers/vzt_write.c:1589:1: note: len is decremented', new value is 31
     gtkwave-gtk3-3.3.127/src/helpers/vzt_write.c:1591:7: note: Assignment 'i=0', assigned value is 0
     gtkwave-gtk3-3.3.127/src/helpers/vzt_write.c:1593:29: note: Shift
Explanation: `len` is clamped to 32 and then decremented to 31. In the first loop iteration (i=0) the code evaluates `1<<(len-i)`, which is `1<<31` on a signed 32-bit int. Shifting into the sign bit is undefined behaviour in C, and any symbol of length 32 reaches this path. The new shiftTooManyBitsSigned warning is a genuine true positive; the fix would be `1u<<...`.

---- 7 / 18 ----
Verdict:     NEUTRAL (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/libb/libbtbb/libbtbb_2020.12.R1.orig.tar.gz
Result:      main libbtbb-2020-12-R1/lib/src/pcapng-bt.c:0:0: debug: ValueFlow maximum iterations exceeded [valueFlowMaxIterations]
Explanation: The PR removed a 'ValueFlow maximum iterations exceeded' debug message from pcapng-bt.c. This message depends on how many values ValueFlow propagates. The PR adds new impossible values on casts and drops some impossible bounds through unsigned arithmetic, so the iteration count changed as a side effect. It does not show that Cppcheck understands the code better. No source code is shown and no warnings changed. The effect on users is negligible.

---- 8 / 18 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/libs/libsecp256k1/libsecp256k1_0.8.0.orig.tar.gz
Result:      your bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:699:108: error: Shifting 32-bit value by 32 bits is undefined behaviour [shiftTooManyBits]
     bitcoin-core-secp256k1-18f07c4/src/scalar_impl.h:166:49: note: Calling function 'secp256k1_scalar_mul_shift_var', 4th argument '384' value is 384
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:697:22: note: Assignment 'shiftlow=shift&0x1F', assigned value is 0
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:698:20: note: Assignment 'shifthigh=32-shiftlow', assigned value is 32
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:699:108: note: Shift
Explanation: The left shift `l[1 + shiftlimbs] << shifthigh` sits inside `shift < 480 && shiftlow ? ... : 0`. It only runs when shiftlow is non-zero, so shifthigh = 32 - shiftlow is always in [1,31]. With shift=384, shiftlow is 0, the guard is false, and the shift is never executed. Cppcheck ignores the `&& shiftlow` condition, so this new shiftTooManyBits error is a false positive. Main did not report it, so the PR made the output worse.

---- 9 / 18 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/libs/libsecp256k1/libsecp256k1_0.8.0.orig.tar.gz
Result:      your bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:700:108: error: Shifting 32-bit value by 32 bits is undefined behaviour [shiftTooManyBits]
     bitcoin-core-secp256k1-18f07c4/src/scalar_impl.h:166:49: note: Calling function 'secp256k1_scalar_mul_shift_var', 4th argument '384' value is 384
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:697:22: note: Assignment 'shiftlow=shift&0x1F', assigned value is 0
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:698:20: note: Assignment 'shifthigh=32-shiftlow', assigned value is 32
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:700:108: note: Shift
Explanation: Line 700 does `l[2 + shiftlimbs] << shifthigh` inside `shift < 448 && shiftlow ? ... : 0`. When shift is 384, shiftlow is 0, so shifthigh is 32, but then `shiftlow` is false and the shift is never executed. The warning is a false positive: Cppcheck ignores the `&& shiftlow` guard in the ternary. It is a new false positive introduced by the PR's value-flow changes (likely the shift < 448 comparison/cast handling disturbing condition tracking), so it is a regression.

---- 10 / 18 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/libs/libsecp256k1/libsecp256k1_0.8.0.orig.tar.gz
Result:      your bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:701:108: error: Shifting 32-bit value by 32 bits is undefined behaviour [shiftTooManyBits]
     bitcoin-core-secp256k1-18f07c4/src/scalar_impl.h:166:49: note: Calling function 'secp256k1_scalar_mul_shift_var', 4th argument '384' value is 384
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:697:22: note: Assignment 'shiftlow=shift&0x1F', assigned value is 0
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:698:20: note: Assignment 'shifthigh=32-shiftlow', assigned value is 32
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:701:108: note: Shift
Explanation: With shift=384, shiftlow=0 and shifthigh=32. On line 701 the shift 'l[3+shiftlimbs] << shifthigh' only runs when 'shift < 416 && shiftlow' is true. Since shiftlow is 0, that guard is false and the shift is never executed. The outer 'shift < 448' guard also holds, but the inner '&& shiftlow' protects the shift. The warning is a false positive: the PR's new impossible-value or cast changes make Cppcheck ignore the shiftlow guard. Lines 703-705 are even unreachable, since 'shift < 384' is false for shift=384. This is a newly added false positive.

---- 11 / 18 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/libs/libsecp256k1/libsecp256k1_0.8.0.orig.tar.gz
Result:      your bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:702:108: error: Shifting 32-bit value by 32 bits is undefined behaviour [shiftTooManyBits]
     bitcoin-core-secp256k1-18f07c4/src/scalar_impl.h:166:49: note: Calling function 'secp256k1_scalar_mul_shift_var', 4th argument '384' value is 384
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:697:22: note: Assignment 'shiftlow=shift&0x1F', assigned value is 0
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:698:20: note: Assignment 'shifthigh=32-shiftlow', assigned value is 32
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:702:108: note: Shift
Explanation: With shift=384, shiftlow = 0, so shifthigh = 32. The shift `l[...] << shifthigh` sits behind the guard `shift < 384 && shiftlow`, which is false when shiftlow is 0. The shift is never evaluated with 32 bits, so this is a false positive. Cppcheck appears to have lost the condition handling for the ternary/&& guard, probably because the new impossible-value changes alter how values flow through `shift & 0x1F` and `32 - shiftlow`. The PR adds the warning on all lines 699-705, so this is a new false positive.

---- 12 / 18 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/libs/libsecp256k1/libsecp256k1_0.8.0.orig.tar.gz
Result:      your bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:703:108: error: Shifting 32-bit value by 32 bits is undefined behaviour [shiftTooManyBits]
     bitcoin-core-secp256k1-18f07c4/src/scalar_impl.h:166:49: note: Calling function 'secp256k1_scalar_mul_shift_var', 4th argument '384' value is 384
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:697:22: note: Assignment 'shiftlow=shift&0x1F', assigned value is 0
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:698:20: note: Assignment 'shifthigh=32-shiftlow', assigned value is 32
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:703:108: note: Shift
Explanation: With shift=384, shiftlow is 0, and the shift `l[...] << shifthigh` on line 703 is guarded twice. It only runs when `shift < 352 && shiftlow` is true, and `shiftlow` is 0. The outer `shift < 384` condition is also false, so the whole expression is skipped and only 0 is used. A shift by 32 can never happen here, so the warning is a false positive. The same pattern produces seven such new warnings. The PR's new handling of casts and unsigned arithmetic seems to have disturbed how values flow, so Cppcheck now ignores the short-circuit guard and reports this new false positive.

---- 13 / 18 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/libs/libsecp256k1/libsecp256k1_0.8.0.orig.tar.gz
Result:      your bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:704:108: error: Shifting 32-bit value by 32 bits is undefined behaviour [shiftTooManyBits]
     bitcoin-core-secp256k1-18f07c4/src/scalar_impl.h:166:49: note: Calling function 'secp256k1_scalar_mul_shift_var', 4th argument '384' value is 384
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:697:22: note: Assignment 'shiftlow=shift&0x1F', assigned value is 0
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:698:20: note: Assignment 'shifthigh=32-shiftlow', assigned value is 32
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:704:108: note: Shift
Explanation: The shift `l[6 + shiftlimbs] << shifthigh` only runs when `shiftlow` is nonzero, because of the guard `shift < 320 && shiftlow ? ... : 0`. If shiftlow is nonzero, then shifthigh = 32 - shiftlow lies in 1..31, so a shift by 32 never happens. Also, with shift=384 the condition `shift < 352` is false, so the whole expression on line 704 is never evaluated. Cppcheck now ignores both conditions and reports a false positive. The PR's change to impossible-bound propagation seems to have removed knowledge that it used before to suppress this warning.

---- 14 / 18 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/libs/libsecp256k1/libsecp256k1_0.8.0.orig.tar.gz
Result:      your bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:705:108: error: Shifting 32-bit value by 32 bits is undefined behaviour [shiftTooManyBits]
     bitcoin-core-secp256k1-18f07c4/src/scalar_impl.h:166:49: note: Calling function 'secp256k1_scalar_mul_shift_var', 4th argument '384' value is 384
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:697:22: note: Assignment 'shiftlow=shift&0x1F', assigned value is 0
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:698:20: note: Assignment 'shifthigh=32-shiftlow', assigned value is 32
     bitcoin-core-secp256k1-18f07c4/src/scalar_8x32_impl.h:705:108: note: Shift
Explanation: The shift `l[7 + shiftlimbs] << shifthigh` sits behind the guard `shift < 288 && shiftlow ? ... : 0`, so it only runs when shiftlow is nonzero. Then shifthigh = 32 - shiftlow is at most 31. With shift=384, shiftlow is 0, so the outer `shift < 320` is false and the shift is never evaluated. The new warning ignores both conditions and is a false positive. The PR's changes to impossible-value handling likely broke the conditional pruning.

---- 15 / 18 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/libt/libtcod/libtcod_1.24.0+dfsg.orig.tar.xz
Result:      your libtcod-1.24.0/samples/worldgen/util_worldgen.cpp:553:48: error: Array 'clouds[400][400]' accessed at index clouds[-2147483648][*], which is out of bounds. [negativeIndex]
Explanation: `colsToTranslate` is `static_cast<int>(cloudDx)` with `cloudDx >= 1.0f`, and the loop starts at `x = colsToTranslate`. So `x - colsToTranslate` is always >= 0 and below `HM_WIDTH`, and the index -2147483648 cannot occur. The new impossible-bound values that the PR attaches to the int cast are being misused to produce this bogus negative index. This is a new false positive.

---- 16 / 18 ----
Verdict:     REGRESSION (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/libt/libtcod/libtcod_1.24.0+dfsg.orig.tar.xz
Result:      your libtcod-1.24.0/samples/worldgen/util_worldgen.cpp:565:15: error: Array 'clouds[400][400]' accessed at index clouds[-2147483247][*], which is out of bounds. [negativeIndex]
Explanation: `colsToTranslate` is `static_cast<int>(cloudDx)`, and `cloudDx` is only ever a small per-frame increment (elapsedTime*5) that gets reduced back below 1. The reported index -2147483247 is 400 - INT_MAX. So Cppcheck took INT_MAX, the edge of the int type range that the PR's new cast bounds introduce, and treated it as a real possible value of `colsToTranslate`. Nothing in the code suggests such a value. This is a new false positive negativeIndex error caused by the PR.

---- 17 / 18 ----
Verdict:     IMPROVEMENT (low confidence)
Package:     https://ftp.debian.org/debian/pool/main/u/udunits/udunits_2.2.28.orig.tar.xz
Result:      main udunits-2.2.28/lib/unitcore.c:0:0: debug: ValueFlow maximum iterations exceeded [valueFlowMaxIterations]
Explanation: The 'ValueFlow maximum iterations exceeded' debug message for unitcore.c disappears. In the same run, the false positive 'imonth>12 is always false' in the Julian-day conversion is also removed; je can reach 14 or 15 there, so imonth>12 is reachable. The PR changes how impossible bounds are created on casts and stops them from passing through unsigned arithmetic. This changes value propagation in this cast-heavy code, and ValueFlow now finishes within the iteration limit. Together with the removed false positive, this suggests better analysis of the file, not lost coverage. The link between the two is not certain, and debug output rarely affects users.

---- 18 / 18 ----
Verdict:     IMPROVEMENT (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/u/udunits/udunits_2.2.28.orig.tar.xz
Result:      main udunits-2.2.28/lib/unitcore.c:285:16: style: Condition 'imonth>12' is always false [knownConditionTrueFalse]
     udunits-2.2.28/lib/unitcore.c:267:16: note: Assuming that condition 'julday<2299161' is not redundant
     udunits-2.2.28/lib/unitcore.c:273:23: note: Assignment 'ja=julday+1+ia-(int)(0.25*ia)', assigned value is 2299171
     udunits-2.2.28/lib/unitcore.c:276:8: note: jb is assigned 'ja+1524' here.
     udunits-2.2.28/lib/unitcore.c:280:10: note: Assignment 'je=(int)((jb-jd)/30.6001)', assigned value is 11
     udunits-2.2.28/lib/unitcore.c:284:17: note: Assignment 'imonth=je-1', assigned value is less than 11
     udunits-2.2.28/lib/unitcore.c:285:16: note: Condition 'imonth>12' is always false
Explanation: This is the standard Julian-day to Gregorian-date algorithm. Here `je` is computed as `(int)((jb-jd)/30.6001)` and normally ranges up to 14 or 15. So `imonth = je-1` can be 13 or 14, and the `imonth > 12` adjustment is required. Main's note chain is bogus: it concludes 'assigned value is less than 11' from a single value of 11. The 'always false' warning was therefore a false positive, and its removal is an improvement.