AI review of 2026-10-13_10-16-57-fdaaa169aea9-results.txt PR: #8819 https://github.com/cppcheck-opensource/cppcheck/pull/8819 Tested: fdaaa169aea90be6531d71f294b4e3b45c87a932 Merge base: b2d83612a1d235901d70a77d25c21759014e4919 Reviewed: 2026-10-13 20:37:07 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 237 in the report (random sample), 34 not reviewed: valueFlowMaxIterations Verdicts: 23 improvement, 1 neutral, 23 regression, 3 unclear Tokens: 115952 input, 1396360 cache read, 349090 cache write, 31083 output The verdicts are written by AI and can be wrong. ---- 1 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/a/afterstep/afterstep_2.2.12.orig.tar.bz2 Result: main afterstep-devel-2.2.12/libAfterImage/libjpeg/jcparam.c:191:3: warning: Buffer is accessed out of bounds: (void*)((*htblptr)->huffval) [bufferAccessOutOfBounds] afterstep-devel-2.2.12/libAfterImage/libjpeg/jcparam.c:188:32: note: Assuming that condition 'nsymbols>256' is not redundant afterstep-devel-2.2.12/libAfterImage/libjpeg/jcparam.c:191:3: note: Buffer overrun Explanation: `huffval` is a 256-byte array, and the copy at line 191 only happens after the check `nsymbols < 1 || nsymbols > 256` calls `ERREXIT`. In libjpeg, `ERREXIT` calls `err->error_exit` through a function pointer, and that handler is required never to return. Cppcheck cannot see that, so main assumed `nsymbols > 256` could reach the copy. In practice that path is unreachable, so the warning was a false positive. The PR removes it, most likely because `nsymbols * SIZEOF(UINT8)` is unsigned arithmetic: the new wrap-around guard drops the range-bound values coming from `nsymbols`. The removal is somewhat a side effect of being more conservative rather than of Cppcheck understanding the noreturn handler. Still, losing this false positive helps users. ---- 2 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/betaradio/betaradio_1.6.orig.tar.xz Result: main betaradio-1.6/libltdl/argz.c:92:7: style: Condition 'argz_len' is always true [knownConditionTrueFalse] betaradio-1.6/libltdl/argz.c:91:15: note: Assignment 'argz_len=1+strlen(str)', assigned value is greater than 0 betaradio-1.6/libltdl/argz.c:92:7: note: Condition 'argz_len' is always true Explanation: `argz_len = 1 + strlen(str)` cannot be 0. `strlen` returns at most SIZE_MAX-1, because the string needs a terminating '\0' inside an object of at most SIZE_MAX bytes. So the size_t addition never wraps, and `if (argz_len)` is always true. The removed warning was a true positive. The PR's new wrap-around handling treats `1 + strlen(...)` as an unsigned result that might wrap and drops the lower bound, so this valid knownConditionTrueFalse finding is lost. ---- 3 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/bladerf/bladerf_0.2025.10.orig.tar.xz Result: your bladerf-0.2025.10/thirdparty/analogdevicesinc/no-OS/Pmods/PmodCDC1/AD7156.c:179:32: error: Shifting by a negative value is undefined behaviour [shiftNegative] Explanation: `AD7156_BurstWriteReg` computes `0xFF << 8*(size-3)` and `>> 8*(size-3)` on line 179, and `0xFF << 8*(size-4)` on line 180. The new warnings appear on exactly these three shifts, not on line 178. That pattern fits a caller passing `size == 2`, which is the natural size for this device's 16-bit threshold and sensitivity registers. With `size == 2`, the shift counts are -8 and -16, which is undefined behaviour in C. The code really performs these negative shifts, so the new shiftNegative warnings look like true positives that main missed. The callers are not shown, hence medium confidence. ---- 4 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/bladerf/bladerf_0.2025.10.orig.tar.xz Result: your bladerf-0.2025.10/thirdparty/analogdevicesinc/no-OS/Pmods/PmodCDC1/AD7156.c:179:52: error: Shifting by a negative value is undefined behaviour [shiftNegative] Explanation: In AD7156_BurstWriteReg, line 179 shifts by `8 * (size - 3)`. The new warnings appear on lines 179 and 180 but not on 177 or 178. That pattern fits a caller passing size == 2, which is typical for writing this chip's 16-bit threshold/sensitivity registers. With size == 2, `size - 3` is -1, so the shift count is -8, and shifting by a negative amount is undefined behaviour in C. The code really performs these shifts unconditionally whatever the size, so the new shiftNegative warning is a true positive that main missed. ---- 5 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/b/bladerf/bladerf_0.2025.10.orig.tar.xz Result: your bladerf-0.2025.10/thirdparty/analogdevicesinc/no-OS/Pmods/PmodCDC1/AD7156.c:180:32: error: Shifting by a negative value is undefined behaviour [shiftNegative] Explanation: In AD7156_BurstWriteReg, the shift counts are 8*(size-N). The new warnings appear exactly where size==2 would make the count negative: line 179 (size-3 = -1, so -8) and line 180 (size-4 = -2, so -16). Line 178 (size-1) and line 177's counterpart for size-2 are not flagged, which fits a caller passing size 2. The AD7156 threshold and sensitivity registers are 16-bit, so callers very likely pass size 2. Shifting by a negative count is undefined behaviour, so this looks like a real bug that main missed. The calling code is not shown here, hence medium confidence. ---- 6 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/cataclysm-dda/cataclysm-dda_0.I-1.orig.tar.xz Result: main CleverRaven-Cataclysm-DDA-0fb5d5b/src/third-party/zstd/compress/zstd_lazy.c:1673:32: style: Condition 'mlRep>=4' is always true [knownConditionTrueFalse] CleverRaven-Cataclysm-DDA-0fb5d5b/src/third-party/zstd/compress/zstd_lazy.c:1670:80: note: Assignment 'mlRep=ZSTD_count(ip+4,ip+4-offset_1,iend)+4', assigned value is greater than 3 CleverRaven-Cataclysm-DDA-0fb5d5b/src/third-party/zstd/compress/zstd_lazy.c:1673:32: note: Condition 'mlRep>=4' is always true Explanation: `mlRep = ZSTD_count(...) + 4` is a `size_t`. `ZSTD_count` returns the number of matching bytes, which is bounded by the input buffer size, so the `+4` cannot wrap in practice. The check `mlRep >= 4` is therefore genuinely redundant, and main's knownConditionTrueFalse warning was a true positive. The PR now treats any unsigned `+` with an operand of unknown range as possibly wrapping, so it drops the lower bound and loses this valid warning. That makes Cppcheck more conservative, but here it costs a correct diagnostic rather than fixing a false positive. ---- 7 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/csound/csound_6.18.1+dfsg.orig.tar.xz Result: main csound-6.18.1/Opcodes/pvinterp.c:509:45: style: Condition '(int32_t)specwp' is always true [knownConditionTrueFalse] Explanation: In csound's PVOC code, `specwp` is normally declared as `int32_t specwp = (int32_t)*p->ispecwp;`, but that declaration is not in the excerpt shown. The right operand of `||` is only evaluated when `specwp == 0` is false. If `specwp` is an integer, `(int32_t) specwp` is then always nonzero, so 'always true' is a genuine redundant condition. The PR adds impossible-range values to integral casts and changes how unsigned arithmetic and inferred values propagate. That apparently stopped Cppcheck from carrying the `specwp != 0` knowledge through the cast, so a true positive was lost. Confidence is not high because the type of `specwp` is not visible here: if it were a float, values like 0.5 would make the warning a false positive. ---- 8 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/d/ddrutility/ddrutility_2.8.orig.tar.xz Result: main ddru_ntfsbitmap.c:1291:18: warning: Uninitialized variable: lastbit [uninitvar] ddru_ntfsbitmap.c:1284:11: note: Assuming condition is false ddru_ntfsbitmap.c:1291:18: note: Uninitialized variable: lastbit Explanation: `firstbit` is initialised to true, so on the first pass through the inner loop `lastbit = bit` always runs before the comparison at line 1291. After that, `firstbit` is false but `lastbit` already holds a value. The path where the condition at 1284 is false with `lastbit` never assigned cannot happen, so main's uninitvar warning was a false positive. The PR removing it is good for users. The removal may be a side effect of other valueflow changes rather than a targeted fix, which is why confidence is medium. ---- 9 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/d/ddrutility/ddrutility_2.8.orig.tar.xz Result: your ddru_ntfsbitmap.c:1363:37: warning: Uninitialized variable: position_bytes [uninitvar] ddru_ntfsbitmap.c:1276:14: note: Assuming condition is false ddru_ntfsbitmap.c:1363:37: note: Uninitialized variable: position_bytes Explanation: The new warning says that if the loop condition at line 1276 is false from the start (zero iterations), `position_bytes` is read uninitialized at line 1363. Within the loop, it is only assigned when `smallgap == false`. That could make this a true positive. However, the declarations and the loop at 1276 are not shown, so I cannot tell whether zero iterations is actually feasible or whether the variable is initialized elsewhere. The warning also appeared alongside the disappearance of the `lastbit` warning, which suggests a shift in the value-flow path rather than a clearly better understanding of the code. There is not enough context to judge. ---- 10 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/d/ddrutility/ddrutility_2.8.orig.tar.xz Result: your ddru_ntfsbitmap.c:1363:54: warning: Uninitialized variable: size_bytes [uninitvar] ddru_ntfsbitmap.c:1276:14: note: Assuming condition is false ddru_ntfsbitmap.c:1363:54: note: Uninitialized variable: size_bytes Explanation: The new warning says `size_bytes` is read uninitialized at line 1363 when the condition at line 1276 is false. That condition is probably the main loop condition. `size_bytes` is only assigned inside the loop, under `smallgap == false`. Whether this is a real bug depends on code that is not shown: how `size_bytes` is declared and initialized, and what the condition at 1276 is. If the loop can run zero times, or the `smallgap == false` branch is never taken, the read is truly uninitialized and the warning is correct. If the loop bound is always positive, it is a false positive. The PR changes how unsigned arithmetic bounds and impossible values propagate, which could make Cppcheck treat that condition as possibly false. There is not enough context to tell whether that is more or less accurate. ---- 11 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/d/dlt-daemon/dlt-daemon_3.0.0.orig.tar.gz Result: main dlt-daemon-3.0.0/tests/gtest_dlt_user.cpp:2597:47: style: Condition 'index(user_message_after_truncated_size+str_truncate_message_length)', assigned value is greater than 4 dlt-daemon-3.0.0/tests/gtest_dlt_user.cpp:2597:47: note: Condition 'indexmask' is not redundant firejail-0.9.80/src/firejail/network_main.c:76:30: note: Assignment 'range=~br->mask+1', assigned value is greater than 4294967296 firejail-0.9.80/src/firejail/network_main.c:78:13: note: Condition 'range<4' is always false Explanation: br->mask is a uint32_t, so `~br->mask + 1` is unsigned arithmetic that wraps. With mask 0xFFFFFFFE (/31) the range is 2, and with mask 0xFFFFFFFF it is 1, so `range < 4` can be true. Main failed to model the wraparound and claimed the assigned value is 'greater than 4294967296', which is impossible for a uint32_t, and so reported the condition as always false. The PR stops propagating range bounds through unsigned arithmetic that may wrap, which removes this false positive. ---- 14 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/gsl/gsl_2.8+dfsg.orig.tar.gz Result: your gsl-2.8/specfunc/legendre_con.c:1087:28: warning: Either the condition 'x<=-1.0' is redundant or sqrt() argument nr 1 can have invalid value. The value is -2 but the valid values are '0.0:'. [invalidFunctionArg] gsl-2.8/specfunc/legendre_con.c:1059:8: note: Assuming that condition 'x<=-1.0' is not redundant gsl-2.8/specfunc/legendre_con.c:1087:28: note: Invalid argument Explanation: Line 1087 is in the final else branch, so it only runs when x > 1, because `x <= -1.0`, `x < 1.0` and `x == 1.0` were all ruled out earlier. Also, DOMAIN_ERROR returns from the function. So x-1.0 is positive and x+1.0 > 2, and sqrt() can never get -2. The new float-bound condition handling in SimpleConditionHandler (`>=`/`<=` with a float literal) gives x a value of -1 from `x <= -1.0`. That value then wrongly leaks past the return and the later else-if conditions. This is a new false positive. ---- 15 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/gsl/gsl_2.8+dfsg.orig.tar.gz Result: your gsl-2.8/specfunc/log.c:119:23: warning: Either the condition 'x<=0.0' is redundant or log() argument nr 1 can have invalid value. The value is 0 but the valid values are '4.94066e-324:'. [invalidFunctionArg] gsl-2.8/specfunc/log.c:115:8: note: Assuming that condition 'x<=0.0' is not redundant gsl-2.8/specfunc/log.c:119:23: note: Invalid argument Explanation: log(x) on line 119 is in the else branch of 'if (x <= 0.0)', so x > 0 there and the argument cannot be 0. The new floating-point condition handler in the PR adds bound values for 'x <= 0.0', and these get applied to the wrong branch. The warning is a false positive. ---- 16 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/gst-plugins-good1.0/gst-plugins-good1.0_1.29.2.orig.tar.xz Result: main gst-plugins-good-1.29.2/gst/matroska/ebml-write.c:315:23: warning: Shifting 32-bit value by 34359738360 bits is undefined behaviour. See condition at line 321. [shiftTooManyBits] gst-plugins-good-1.29.2/gst/matroska/ebml-write.c:321:13: note: Assuming that condition 'bytes==0' is not redundant gst-plugins-good-1.29.2/gst/matroska/ebml-write.c:315:23: note: Shift Explanation: In the loop condition, `(bytes - 1) * 8` is computed before `bytes > 0` is checked. `bytes` is an unsigned int, so once it reaches 0 the shift count wraps to (0xFFFFFFFF*8) mod 2^32 = 4294967288. The shiftTooManyBits warning is a real issue: the shift is undefined behaviour for an invalid ID. Main reported 34359738360, which is the unwrapped 64-bit result and not a value the shift count can actually hold. The PR now truncates unsigned arithmetic results to the result type, so it reports 4294967288. The same true positive is kept, with a more accurate value. ---- 17 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/h/htscodecs/htscodecs_1.6.7.orig.tar.gz Result: main samtools-htscodecs-9f11619/htscodecs/rANS_static4x16pr.c:1223:23: style: Condition '*out_size==0' is always false [knownConditionTrueFalse] samtools-htscodecs-9f11619/htscodecs/rANS_static4x16pr.c:1222:45: note: Calling function 'rans_compress_bound_4x16' returns !<=1 samtools-htscodecs-9f11619/htscodecs/rANS_static4x16pr.c:1223:23: note: Condition '*out_size==0' is always false Explanation: Line 1223 checks whether `rans_compress_bound_4x16()` returned 0. The caller is written to handle a 0 result, which suggests the bound function signals overflow that way. Its result is unsigned arithmetic, roughly `sz + (sz&1) + 2`, computed from `1.05*size` plus constants. With `in_size` up to INT_MAX this can exceed the type range, so the result can wrap or hit the overflow return. Main inferred an impossible lower bound (`returns !<=1`) without accounting for this, so the 'always false' claim was likely a false positive. The PR's unsigned-wrap handling stops propagating such bounds through arithmetic that may wrap, which removes the warning. The bound function's exact body is not shown, hence medium confidence. ---- 18 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/h/htscodecs/htscodecs_1.6.7.orig.tar.gz Result: main samtools-htscodecs-9f11619/htscodecs/varint.h:420:32: error: Signed integer overflow for expression '-(int32_t)(*i&1)'. [integerOverflow] Explanation: `*i & 1` can only be 0 or 1, so `(int32_t)(*i & 1)` is 0 or 1. Negating it gives 0 or -1, which can never overflow. The main warning was a false positive, most likely caused by bogus range values flowing through the cast. The PR adds impossible-range bounds for integral casts and fixes how values are propagated through unary minus, so removing this warning is correct. ---- 19 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/ipset/ipset_7.24.orig.tar.bz2 Result: main ipset-7.24/libltdl/lt__argz.c:92:7: style: Condition 'argz_len' is always true [knownConditionTrueFalse] ipset-7.24/libltdl/lt__argz.c:91:15: note: Assignment 'argz_len=1+strlen(str)', assigned value is greater than 0 ipset-7.24/libltdl/lt__argz.c:92:7: note: Condition 'argz_len' is always true Explanation: `argz_len = 1 + strlen(str)` is a size_t. strlen() can never return SIZE_MAX, because the string plus its terminator must fit in memory. So the sum cannot wrap to 0, and `if (argz_len)` on line 92 really is always true. The old warning was a true positive pointing at a redundant check. The PR's new rule that unsigned `+` may wrap is too conservative here and drops a valid knownConditionTrueFalse finding. ---- 20 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/j/jags/jags_5.0.0.orig.tar.gz Result: main JAGS-5.0.0/libltdl/lt__argz.c:89:7: style: Condition 'argz_len' is always true [knownConditionTrueFalse] JAGS-5.0.0/libltdl/lt__argz.c:88:15: note: Assignment 'argz_len=1+strlen(str)', assigned value is greater than 0 JAGS-5.0.0/libltdl/lt__argz.c:89:7: note: Condition 'argz_len' is always true Explanation: `argz_len = 1 + strlen(str)` cannot be 0 in practice. strlen() can return at most SIZE_MAX-1, because the string plus its terminator must fit in one object, so the unsigned addition never wraps. The `if (argz_len)` check at line 89 is therefore always true, and the knownConditionTrueFalse warning was a true positive. The PR now treats unsigned `+` as possibly wrapping when the operand ranges are unbounded, so it drops the warning. That is overly conservative here and loses a correct (if minor, style-level) diagnostic. ---- 21 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/l/lcms2/lcms2_2.19.1.orig.tar.gz Result: your lcms2-2.19.1/utils/tificc/tificc.c:136:24: portability: Shifting a negative value is technically undefined behaviour [shiftNegativeLHS] Explanation: FromLabV2ToLabV4(x) can really get a negative argument. At line 176 the caller passes `accum16[1] - 0x8000` whenever `accum16[1] > 0x7f00`. For inputs 0x7f01..0x7fff, the uint16 is promoted to int and the result is negative, down to -255. Then `((x << 8) | x)` is negative, and line 136 shifts it at column 24, the `>>`. So the new shiftNegativeLHS warning reflects a feasible negative left operand driven by real input data, which makes it likely a true positive. One caveat: right-shifting a negative value is implementation-defined rather than undefined, so the wording is a bit strong, but this is Cppcheck's existing message for this check. ---- 22 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/l/lr/lr_1.5.1.orig.tar.xz Result: main lr-1.5.1/lr.c:2455:9: warning: Either the condition 'prefixl>4096' is redundant or the array 'pathbuf[4097]' is accessed at index 4097, which is out of bounds. [arrayIndexOutOfBoundsCond] lr-1.5.1/lr.c:2450:14: note: Assuming that condition 'prefixl>4096' is not redundant lr-1.5.1/lr.c:2455:9: note: Array index out of bounds Explanation: After the check `if (prefixl > PATH_MAX) return -1;`, `prefixl` can still be exactly 4096. `pathbuf` has 4097 elements (valid indices 0..4096), so `pathbuf[prefixl + 1]` writes `pathbuf[4097]`, one past the end. The warning in main was a true positive. The PR's new unsigned-wrap handling stops the range bound on `prefixl` (likely a `size_t`) from propagating through `prefixl + 1`, so the real out-of-bounds write is no longer reported. ---- 23 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libb/libbitarray/libbitarray_2.0.orig.tar.gz Result: main BitArray-2.0/dev/bit_array_test.c:818:12: warning: Buffer is accessed out of bounds: counts [bufferAccessOutOfBounds] BitArray-2.0/dev/bit_array_test.c:805:15: note: Assign counts, buffer with size 2000 BitArray-2.0/dev/bit_array_test.c:800:17: note: Assignment 'max_len=500', assigned value is 500 BitArray-2.0/dev/bit_array_test.c:811:5: note: Assuming that condition 'len<=max_len' is not redundant BitArray-2.0/dev/bit_array_test.c:818:12: note: Buffer overrun Explanation: `counts` is malloc'd with 500*sizeof(int) = 2000 bytes. `len` comes from RAND(max_len-5)+5 and is asserted to be <= max_len, so `len*sizeof(int)` is at most 2000 bytes and the memset stays in bounds. The removed bufferAccessOutOfBounds warning was therefore a false positive. It likely disappeared because the PR no longer propagates range bounds through unsigned arithmetic that might wrap (`len*sizeof(int)`). That is coarser reasoning, not proof of safety, but for this code the outcome is correct. ---- 24 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libm/libmaus2/libmaus2_2.0.813+ds.orig.tar.xz Result: your libmaus2-2.0.813-release-20221210220409/src/test/testBitIO.cpp:59:46: error:inconclusive: Shifting 64-bit value by 4294967295 bits is undefined behaviour [shiftTooManyBits] libmaus2-2.0.813-release-20221210220409/src/test/testBitIO.cpp:135:31: note: Assignment 'numbits=0', assigned value is 0 libmaus2-2.0.813-release-20221210220409/src/test/testBitIO.cpp:146:29: note: Calling function 'putBitsVector', 3rd argument 'numbits' value is 0 libmaus2-2.0.813-release-20221210220409/src/test/testBitIO.cpp:59:46: note: Shift Explanation: In `putBitsVector`, `numbits` is `unsigned int`. When it is 0, `numbits-1` wraps to 4294967295, and shifting a 64-bit value by that amount is undefined behaviour. The error path shows `numbits=0` at line 135 being passed at line 146. That is most likely a loop starting at 0, like the one at line 94, though lines 135–146 are not shown. The PR now truncates point values of unsigned arithmetic to the result type, so Cppcheck computes the wrapped value instead of -1. The warning describes a real UB path, so this looks like a newly found true positive. ---- 25 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/mgcv/mgcv_1.9-4.orig.tar.gz Result: your mgcv/src/misc.c:63:35: warning: Either the condition 'xi/2>=0.5' is redundant or log() argument nr 1 can have invalid value. The value is 0 but the valid values are '4.94066e-324:'. [invalidFunctionArg] mgcv/src/misc.c:62:15: note: Assuming that condition 'xi/2>=0.5' is not redundant mgcv/src/misc.c:63:35: note: Invalid argument Explanation: Line 63 only runs in the else branch of `if (xi/2>=.5)`, so there `xi/2 < 0.5` holds strictly. That makes `.5-xi/2` strictly positive, and log() can never receive 0. The new float `>=`/`<=` condition handling in the PR gives the false branch an Upper bound equal to the literal 0.5 itself. That wrongly includes the excluded endpoint and produces the value 0 for the log argument. The new invalidFunctionArg warning is a false positive. ---- 26 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/minc-tools/minc-tools_2.3.00+dfsg.orig.tar.gz Result: your minc-tools-2.3.00+dfsg/progs/minccalc/eval.c:211:47: warning: Either the condition 'vals[0]<=0.0' is redundant or log() argument nr 1 can have invalid value. The value is 0 but the valid values are '4.94066e-324:'. [invalidFunctionArg] minc-tools-2.3.00+dfsg/progs/minccalc/eval.c:208:25: note: Assuming that condition 'vals[0]<=0.0' is not redundant minc-tools-2.3.00+dfsg/progs/minccalc/eval.c:211:47: note: Invalid argument Explanation: The code checks `if (vals[0] <= 0.0)` and only calls `log(vals[0])` in the else branch, where vals[0] > 0. The argument can never be 0 there, so the new invalidFunctionArg warning is a false positive. It comes from the PR's new float condition handling for `<=`/`>=`. That code puts the value 0.0 as an Upper bound into the false branch, where it should be an impossible value or exclusive bound. The PR introduced this false positive. ---- 27 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/mpfr4/mpfr4_4.2.2.orig.tar.xz Result: main mpfr-4.2.2/src/sub1sp1_extracted.c:338:20: style: Condition 'sb_1==(uint64_t)0U' is always false [knownConditionTrueFalse] mpfr-4.2.2/src/sub1sp1_extracted.c:336:79: note: Assignment 'sb_1=~(cp0ul1<<(uint32_t)(GMP_NUMB_BITS-d))+(uint64_t)1U', assigned value is greater than 0 mpfr-4.2.2/src/sub1sp1_extracted.c:338:20: note: Condition 'sb_1==(uint64_t)0U' is always false Explanation: `sb_1 = ~(cp0ul1 << ...) + 1` is unsigned 64-bit arithmetic that can wrap to 0, for example when the shifted value is 0. Then `~0 + 1 == 0`, so `sb_1 == 0` can be true. Main's claim that 'assigned value is greater than 0' ignores this wrap-around, so the warning was a false positive. The PR stops propagating range bounds through unsigned arithmetic that may wrap, which removes the warning. That is correct. ---- 28 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/mpfr4/mpfr4_4.2.2.orig.tar.xz Result: main mpfr-4.2.2/src/sub1sp1_extracted.c:452:61: style: Condition 'ap[0U]+((uint64_t)1U<<(uint32_t)st.sh)==(uint64_t)0U' is always false [knownConditionTrueFalse] Explanation: The condition `ap[0] + (1 << sh) == 0` is an overflow check on unsigned 64-bit addition. When `ap[0]` is close to UINT64_MAX the sum wraps to 0, so the condition can be true. The code handles exactly this rounding carry by setting `ap[0]` to 0x8000... and incrementing the exponent. Main wrongly ignored the wrap-around and reported 'always false'. The PR stops propagating range bounds through unsigned arithmetic that may wrap, so this false positive is gone. ---- 29 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/mpfr4/mpfr4_4.2.2.orig.tar.xz Result: main mpfr-4.2.2/src/sub1sp1_extracted.c:491:61: style: Condition 'ap[0U]+((uint64_t)1U<<(uint32_t)st.sh)==(uint64_t)0U' is always false [knownConditionTrueFalse] Explanation: The condition `ap[0U] + ((uint64_t)1U << st.sh) == 0` checks whether an unsigned 64-bit addition wraps to zero. Rounding up a mantissa of all ones overflows exactly like this, and the code handles that case on purpose (it sets ap[0] to 0x8000... and bumps the exponent). Main wrongly said the sum is always greater than 0 because it ignored unsigned wrap-around. The PR treats unsigned arithmetic that may wrap correctly, so this false positive is gone. ---- 30 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/phyml/phyml_3.3.20250515.orig.tar.gz Result: your stephaneguindon-phyml-76a39c8/src/lk.c:2013:38: warning: Either the condition 'site_lk<=0.0' is redundant or log() argument nr 1 can have invalid value. The value is 0 but the valid values are '4.94066e-324:'. [invalidFunctionArg] stephaneguindon-phyml-76a39c8/src/lk.c:2007:22: note: Assuming that condition 'site_lk<=0.0' is not redundant stephaneguindon-phyml-76a39c8/src/lk.c:2013:38: note: Invalid argument Explanation: This is a new false positive. At line 2007 the code checks `site_lk <= .0` and calls `Exit("... site lk <= 0")`, which is PhyML's fatal-error routine and terminates the program. So `log(site_lk)` at line 2013 is only reached with `site_lk > 0`. The warning comes from the PR's new float `<=`/`>=` condition handling, which feeds the possible value 0 past a guard that does not fall through. Main did not report this. ---- 31 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/r/r-bioc-dada2/r-bioc-dada2_1.40.0+dfsg.orig.tar.xz Result: main dada2/src/kmers.cpp:255:25: warning:inconclusive: Either the condition 'kord==NULL' is redundant or there is possible null pointer dereference: kord. [nullPointerRedundantCheck] dada2/src/kmers.cpp:254:12: note: Assuming that condition 'kord==NULL' is not redundant dada2/src/kmers.cpp:255:25: note: Null pointer dereference Explanation: Line 254 checks `kord == NULL` and calls `Rcpp::stop(...)`, which throws an exception and never returns. So `kord` cannot be NULL at the dereference on line 255. The removed nullPointerRedundantCheck was a false positive; main only reported it, as inconclusive, because it did not know that Rcpp::stop is noreturn. The warning probably disappeared as a side effect of the PR's unsigned-wrap handling: `klen = len - k + 1` is unsigned arithmetic, and the change likely means Cppcheck no longer assumes the loop runs. The mechanism is incidental, but dropping this false positive is still good for users. ---- 32 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/r/r-cran-actuar/r-cran-actuar_3.3-7.orig.tar.gz Result: your actuar/src/burr.c:165:26: warning: Either the condition 'limit<=0.0' is redundant or log() argument nr 1 can have invalid value. The value is 0 but the valid values are '4.94066e-324:'. [invalidFunctionArg] actuar/src/burr.c:159:15: note: Assuming that condition 'limit<=0.0' is not redundant actuar/src/burr.c:165:26: note: Invalid argument Explanation: `if (limit <= 0.0) return 0.0;` returns early whenever limit is 0 or negative. So at line 165 limit is strictly greater than 0, and log(limit) is always valid. The PR adds new float condition handling for `>=` and `<=` in SimpleConditionHandler. It gives the false branch a possible value of 0.0 with an upper bound for `limit <= 0.0`, which wrongly includes 0. The excluded boundary point is now treated as reachable after the return. This is a new false positive, and the same pattern produces it across the whole package. ---- 33 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/savvycan/savvycan_220.orig.tar.gz Result: main savvycan-220/dbc/dbcsignaleditor.cpp:110:40: style: Condition 'maxBit<0' is always false [knownConditionTrueFalse] savvycan-220/dbc/dbcsignaleditor.cpp:109:70: note: Assignment 'maxBit=(dbcMessage->len*8)-32+7', assigned value is greater than 6 savvycan-220/dbc/dbcsignaleditor.cpp:110:40: note: Condition 'maxBit<0' is always false Explanation: `dbcMessage->len` is unsigned in SavvyCAN, so `len*8 - 32 + 7` is computed in unsigned arithmetic. When `len < 4` the result wraps to a large unsigned value, and converting that to `int` gives a negative `maxBit`. The `maxBit < 0` guard is therefore reachable. Main wrongly kept the unsigned lower bound across the wrapping subtraction ("assigned value is greater than 6") and reported the condition as always false. The PR stops propagating range bounds through unsigned arithmetic that may wrap, which removes this false positive. ---- 34 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/savvycan/savvycan_220.orig.tar.gz Result: main savvycan-220/dbc/dbcsignaleditor.cpp:771:24: style: Condition 'maxBit<0' is always false [knownConditionTrueFalse] savvycan-220/dbc/dbcsignaleditor.cpp:770:54: note: Assignment 'maxBit=(dbcMessage->len*8)-32+7', assigned value is greater than 6 savvycan-220/dbc/dbcsignaleditor.cpp:771:24: note: Condition 'maxBit<0' is always false Explanation: Line 770 computes `(dbcMessage->len * 8) - 32 + 7`. In SavvyCAN `len` is unsigned, so the expression is evaluated in unsigned arithmetic. For len < 4 it wraps, for example 0xFFFFFFE7 when len is 0. Assigned to `int maxBit`, that becomes a negative value such as -25. So `maxBit < 0` can be true; it is exactly the guard the developer wrote. Main wrongly concluded the value is greater than 6 because it treated the unsigned result as non-negative and ignored wrap-around. The PR stops propagating range bounds through unsigned arithmetic that may wrap, which removes this false positive. ---- 35 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/savvycan/savvycan_220.orig.tar.gz Result: main savvycan-220/dbc/dbcsignaleditor.cpp:782:24: style: Condition 'maxBit<0' is always false [knownConditionTrueFalse] savvycan-220/dbc/dbcsignaleditor.cpp:781:54: note: Assignment 'maxBit=(dbcMessage->len*8)-64+7', assigned value is greater than 6 savvycan-220/dbc/dbcsignaleditor.cpp:782:24: note: Condition 'maxBit<0' is always false Explanation: The note 'assigned value is greater than 6' means Cppcheck took the unsigned lower bound of `dbcMessage->len` (0) and assumed `len*8 - 64 + 7` cannot go below 7. That assumes no wrap-around. Because `len` is unsigned, the expression wraps to a huge unsigned value whenever `len < 8`. Converting that value to `int` gives a negative `maxBit`. So `maxBit < 0` is a real, reachable guard, and the warning was a false positive. The PR stops propagating range bounds through unsigned arithmetic that may wrap, which removes this false positive. ---- 36 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/simutrans/simutrans_124.5.orig.tar.gz Result: main simutrans-124.5/src/simutrans/network/network_cmp_pakset.cc:158:14: style: Condition 'num_paks>0' is always true [knownConditionTrueFalse] simutrans-124.5/src/simutrans/network/network_cmp_pakset.cc:153:45: note: Assignment 'num_paks=addons.get_count()+1', assigned value is greater than 0 simutrans-124.5/src/simutrans/network/network_cmp_pakset.cc:158:14: note: Condition 'num_paks>0' is always true Explanation: `num_paks = addons.get_count()+1` is a uint32, and the code then tests `if(num_paks>0)`. The only way this condition can be false is unsigned wrap-around when `get_count()` returns UINT32_MAX. That would mean a string hashtable of paks holding about 4 billion entries, which is not realistic. The condition is therefore effectively always true, and the old knownConditionTrueFalse warning correctly flagged a redundant check. The PR now treats unsigned `+` as possibly wrapping unless both operands have a proven upper bound, which suppresses this useful true positive. This is a regression, although the PR's reasoning is formally sound. ---- 37 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/swi-prolog/swi-prolog_9.2.9+dfsg.orig.tar.gz Result: main swi-prolog_9.2.9+dfsg/src/libbf/libbf.c:1133:14: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: In mp_neg, `a = 0 - op2[i]` and `v = a - k` are unsigned limb subtractions that are meant to wrap. They are used to compute borrow bits: `k1 = a > v` is 1 when op2[i] != 0, and `v > a` is 1 when a == 0 and k == 1. Neither operand of `|` is always zero. Main reached that conclusion by propagating bounds through unsigned subtraction as if it could not wrap. The PR stops doing that, so the false positive badBitmaskCheck is gone. ---- 38 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/t/taisei/taisei_1.4.4+dfsg.orig.tar.xz Result: main taisei-1.4.4/external/basis_universal/zstd/zstd.c:21793:32: style: Condition 'mlRep>=4' is always true [knownConditionTrueFalse] taisei-1.4.4/external/basis_universal/zstd/zstd.c:21790:80: note: Assignment 'mlRep=ZSTD_count(ip+4,ip+4-offset_1,iend)+4', assigned value is greater than 3 taisei-1.4.4/external/basis_universal/zstd/zstd.c:21793:32: note: Condition 'mlRep>=4' is always true Explanation: `mlRep` is `ZSTD_count(...) + 4`. `ZSTD_count` returns a match length bounded by the buffer size, so the `size_t` addition can never realistically wrap. That makes `mlRep >= 4` always true, and the zstd code carries the redundant check. Main correctly reported this. The PR now treats any unsigned `+` with an unbounded operand as possibly wrapping, so it drops the lower bound and loses a valid `knownConditionTrueFalse` warning. ---- 39 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/t/taisei/taisei_1.4.4+dfsg.orig.tar.xz Result: main taisei-1.4.4/external/basis_universal/zstd/zstd.c:21807:36: style: Condition 'mlRep>=4' is always true [knownConditionTrueFalse] taisei-1.4.4/external/basis_universal/zstd/zstd.c:21804:118: note: Assignment 'mlRep=ZSTD_count_2segments(ip+4,repMatch+4,iend,repMatchEnd,prefixLowest)+4', assigned value is greater than 3 taisei-1.4.4/external/basis_universal/zstd/zstd.c:21807:36: note: Condition 'mlRep>=4' is always true Explanation: `mlRep` is `ZSTD_count_2segments(...) + 4`. The count is a match length bounded by the buffer size, so the `size_t` addition cannot realistically wrap, and `mlRep >= 4` is in practice always true. The old warning was a correct, if minor, redundant-condition finding. The PR now treats an unsigned `+` whose operand has no upper bound as possibly wrapping, so it drops the 'greater than 3' lower bound and loses this true positive. The warning disappeared because of a more conservative assumption, not because Cppcheck understands the code better. ---- 40 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/teakra/teakra_0.0~git20250805.a66efb9.orig.tar.xz Result: your teakra-0.0~git20250805.a66efb9/hwtest/dsptester/source/main.cpp:559:25: error: Array 'grid[15][4]' accessed at index grid[-2147483647][*], which is out of bounds. [negativeIndex] Explanation: `next` starts at `(int)c_row + 1`, where `c_row` is a cursor row that is only ever set to valid grid indices (0..t_row-1). The new index -2147483647 is INT_MIN + 1. It comes from the PR's new cast-range values on `(int)c_row`, carried through `+1`. Cppcheck then treats this type-range bound as a possible concrete index. No real path makes `next` negative, so this new negativeIndex error is a false positive. ---- 41 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/teakra/teakra_0.0~git20250805.a66efb9.orig.tar.xz Result: your teakra-0.0~git20250805.a66efb9/hwtest/dsptester/source/main.cpp:592:29: error: Array 'grid[15][4]' accessed at index grid[*][-2147483647], which is out of bounds. [negativeIndex] Explanation: The loop index is `next = (int)c_col + 1`, and `c_col` is a cursor column that stays inside the grid. The PR adds impossible bounds for cast results. For `(int)c_col` that is just the trivial int range [INT_MIN, INT_MAX]. Propagating that range through `+1` gives `next` a minimum of -2147483647, which `getValueLE(-1)` then reports as a negative index. That bound comes only from the type limits of `int`, not from any real flow, so the new negativeIndex warning on `grid[c_row][next]` is a false positive. The PR's own test array_index_77 aims to avoid exactly this kind of trivial-floor report. ---- 42 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/theano/theano_1.0.5+dfsg.orig.tar.xz Result: your Theano-rel-1.0.5/theano/scalar/c_code/gamma.c:280:17: warning: Either the condition 'prob<=0.0' is redundant or log() argument nr 1 can have invalid value. The value is 0 but the valid values are '4.94066e-324:'. [invalidFunctionArg] Theano-rel-1.0.5/theano/scalar/c_code/gamma.c:257:12: note: Assuming that condition 'prob<=0.0' is not redundant Theano-rel-1.0.5/theano/scalar/c_code/gamma.c:279:13: note: Assuming condition 'prob>0.5' is false Theano-rel-1.0.5/theano/scalar/c_code/gamma.c:279:20: note: Assignment 'p=(prob>0.5)?1-prob:prob', assigned value is 0.0 Theano-rel-1.0.5/theano/scalar/c_code/gamma.c:280:17: note: Invalid argument Explanation: Line 257 returns early when `prob <= 0.0`, so after it `prob > 0`. At line 279, `p` is either `1-prob` (when `prob > 0.5`) or `prob` itself (which is > 0). So `log(p)` never receives 0, and the new invalidFunctionArg warning is a false positive. It comes from the PR's new float condition handling for `<=`/`>=`. On the false branch of `prob<=0.0` it adds a lower bound of 0.0, treating the bound as inclusive even though the comparison is strict. That 0.0 then flows into `p` and the `log()` argument check. The new valueFlowMaxIterations debug message also points to worse analysis. ---- 43 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/t/toxic/toxic_0.11.3.orig.tar.gz Result: main toxic-0.11.3/src/game_chess.c:515:21: style: Condition 'start_l_idx==-1' is always false [knownConditionTrueFalse] toxic-0.11.3/src/game_chess.c:513:26: note: Assuming condition 'left_diag' is false toxic-0.11.3/src/game_chess.c:513:36: note: Assignment 'start_l_idx=left_diag?(((from_l_idx)>(to_l_idx))?(from_l_idx):(to_l_idx))-1:(((from_l_idx)<(to_l_idx))?(from_l_idx):(to_l_idx))+1', assigned value is greater than 0 toxic-0.11.3/src/game_chess.c:515:21: note: Condition 'start_l_idx==-1' is always false Explanation: Both versions report the same knownConditionTrueFalse at line 515; only the attached notes or error path differ. `start_l_idx` is a `size_t`. In the true branch `MAX(from_l_idx, to_l_idx) - 1` could only wrap to SIZE_MAX if both indexes were 0, but `left_diag` requires the letters to differ. So the condition is effectively always false, and the warning is plausibly a true positive in both versions. Main's notes justify it from only the 'left_diag is false' branch, which is a weak explanation. The new version's notes are not shown, so it is impossible to tell whether the message became more or less accurate. ---- 44 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/tree-sitter-c/tree-sitter-c_0.24.1.orig.tar.xz Result: main tree-sitter-c-0.24.1/examples/parser.c:760:48: style: Condition 'i+1>0' is always true [knownConditionTrueFalse] Explanation: Here `i` is uint32_t and `i + 1 > 0` is the usual idiom for a countdown loop that relies on unsigned wrap-around. When i == UINT32_MAX (after decrementing from 0, or when size is 0), `i+1` wraps to 0 and the loop ends. So the condition is not always true. Main wrongly reported it as always true. The PR stops propagating bounds through unsigned arithmetic that may wrap, which removes this false positive. ---- 45 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/tup/tup_0.8.orig.tar.gz Result: your tup-v0.8/src/sqlite3/sqlite3.c:35599:9: warning: Undefined behaviour: float (1e+119) to integer conversion overflow. [floatConversionOverflow] tup-v0.8/src/sqlite3/sqlite3.c:35591:16: note: Assuming that condition 'rr>=1.0e+119L' is not redundant tup-v0.8/src/sqlite3/sqlite3.c:35590:11: note: Assuming condition is true tup-v0.8/src/sqlite3/sqlite3.c:35599:9: note: float to integer conversion Explanation: The new floatConversionOverflow warning is a false positive. In this sqlite3 code, the three while loops keep scaling `rr` down while it is >= 1e119, then >= 1e29, then >= 1e19. After them `rr` is below 1e19, which fits in u64 (max about 1.8e19), so `(u64)rr` cannot overflow. The PR adds a new float `>=` / `<=` condition handler in SimpleConditionHandler. It produces a possible lower-bound value of 1e119 from the `while(rr>=1.0e+119L)` condition, and that value leaks past the loops even though the loops change `rr`. The result is a new false positive. ---- 46 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/t/tuxcmd-modules/tuxcmd-modules_0.6.70+ds.orig.tar.gz Result: your tuxcmd-modules-0.6.70+ds/zip/ZipArchive/ZipExtraField.cpp:36:38: style: Condition 'totalSize<0' is always false [knownConditionTrueFalse] tuxcmd-modules-0.6.70+ds/zip/ZipArchive/ZipExtraField.cpp:35:39: note: Calling function 'GetTotalSize' returns !<=-1 tuxcmd-modules-0.6.70+ds/zip/ZipArchive/ZipExtraField.cpp:36:38: note: Condition 'totalSize<0' is always false Explanation: The same knownConditionTrueFalse warning for 'totalSize<0' is reported before and after the PR. Only the explanatory note changed: GetTotalSize was said to return a value >= 4 ('!<=3') and is now said to return a value >= 0 ('!<=-1'). In ZipArchive, CZipExtraData::GetTotalSize is likely '4 + m_data.GetSize()', an unsigned addition, but that source is not shown here. If so, the PR deliberately drops the lower bound 4 because the unsigned addition could wrap, and keeps only the >= 0 bound from the unsigned type. That is slightly more conservative, and both bounds support the same conclusion. The warning's location, text and validity are unchanged, so the difference hardly matters to users. ---- 47 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-live/vdr-plugin-live_3.5.6.orig.tar.gz Result: your vdr-plugin-live-3.5.6/to_chars10.h:121:28: portability: Undefined behaviour, when '(i-q*100)<<1' is 8391934790 the pointer arithmetic 'digits_100+((i-q*100)<<1)' is out of bounds. [pointerOutOfBoundsCond] vdr-plugin-live-3.5.6/to_chars10.h:177:9: note: Assuming that condition 'i<10000000000000000' is not redundant vdr-plugin-live-3.5.6/to_chars10.h:177:49: note: Calling function 'itoa9_16', 2nd argument 'i' value is 9999999999999999 vdr-plugin-live-3.5.6/to_chars10.h:134:23: note: Calling function 'itoa8_8', 2nd argument 'i-q*100000000' value is 99999999 vdr-plugin-live-3.5.6/to_chars10.h:120:19: note: Assignment 'q=i/100', assigned value is 999999 vdr-plugin-live-3.5.6/to_chars10.h:122:9: note: Assignment 'i=q', assigned value is 999999 vdr-plugin-live-3.5.6/to_chars10.h:121:28: note: Pointer arithmetic overflow Explanation: In itoa8_8, `i` is uint32_t and `q = i/100`, so `i - q*100` is always the remainder in [0,99]. The offset `(i - q*100) << 1` is therefore at most 198, inside the 200-byte digits_100 table. The reported value 8391934790 is impossible. It looks like a wrapped unsigned subtraction (about 2^32 minus a small number) produced by the PR's new unsigned truncation/wrap handling, where `i` and `q` values from different loop iterations were mixed. The pointerOutOfBoundsCond warning is a new false positive. ---- 48 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/x42-plugins/x42-plugins_20260908+ds.orig.tar.xz Result: main x42-plugins-20260908/sisco.lv2/src/sisco.c:179:16: warning: Either the condition 'port<=SCO_OUTPUT5' is redundant or the array 'self->output[4]' is accessed at index 5, which is out of bounds. [arrayIndexOutOfBoundsCond] x42-plugins-20260908/sisco.lv2/src/sisco.c:177:38: note: Assuming that condition 'port<=SCO_OUTPUT5' is not redundant x42-plugins-20260908/sisco.lv2/src/sisco.c:179:16: note: Array index out of bounds Explanation: In `connect_port`, the guard `port >= SCO_INPUT0 && port <= SCO_OUTPUT5` lets odd ports up to 13 reach line 179. There `(port/2)-1` evaluates to 5, while `self->output` has only 4 elements. So the code's own condition permits an out-of-bounds write, and main's arrayIndexOutOfBoundsCond warning is consistent with the source. The PR's new unsigned-wrap handling stops range bounds from propagating through `(port/2) - 1` when it cannot prove there is no wrap. That makes the index value unknown, so the warning is lost. This is a lost true positive, not a removed false positive. In practice the host may never pass those ports for this channel count, which is why confidence is not high. ---- 49 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/x/xrt/xrt_202210.2.13.466+dfsg.orig.tar.gz Result: main xrt-202210.2.13.466+dfsg/tests/validate/xcl_vcu_test/src/xrt_utils.cpp:286:31: warning: Either the condition 'cu_mask>96' is redundant or there is signed integer overflow for expression '1<<(cu_mask-64)'. [integerOverflowCond] xrt-202210.2.13.466+dfsg/tests/validate/xcl_vcu_test/src/xrt_utils.cpp:282:19: note: Assuming that condition 'cu_mask>96' is not redundant xrt-202210.2.13.466+dfsg/tests/validate/xcl_vcu_test/src/xrt_utils.cpp:286:31: note: Integer overflow Explanation: Line 286 runs in the else branch of `cu_mask > 96`, inside `cu_mask > 63`, so `cu_mask` lies in [64, 96]. At `cu_mask == 96` the code evaluates `1 << 32` on a signed int. That is undefined behaviour and a real off-by-one bug: the condition should be `> 95`. The main warning, 'condition cu_mask>96 is redundant or signed integer overflow', is therefore a true positive. The PR's new unsigned-wrap handling apparently stops the bounded value of `cu_mask` from propagating through `cu_mask - 64`, possibly because the two conditions conflict in `isUnsignedArithmeticNoWrap`, so the warning is lost. The related shiftTooManyBits warning disappeared too. Losing a true positive is a regression. ---- 50 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xrt/xrt_202210.2.13.466+dfsg.orig.tar.gz Result: your xrt-202210.2.13.466+dfsg/src/runtime_src/core/pcie/driver/linux/xocl/lib/libfdt/fdt_rw.c:116:20: warning: Expression 'newn-oldn' can have a negative value. That is converted to an unsigned value and used in an unsigned calculation. [signConversion] xrt-202210.2.13.466+dfsg/src/runtime_src/core/pcie/driver/linux/xocl/lib/libfdt/fdt_rw.c:201:41: note: Calling function 'fdt_splice_mem_rsv_', 4th argument '0' value is 0 xrt-202210.2.13.466+dfsg/src/runtime_src/core/pcie/driver/linux/xocl/lib/libfdt/fdt_rw.c:201:38: note: Calling function 'fdt_splice_mem_rsv_', 3rd argument '1' value is 1 xrt-202210.2.13.466+dfsg/src/runtime_src/core/pcie/driver/linux/xocl/lib/libfdt/fdt_rw.c:116:20: note: Negative value is converted to an unsigned value Explanation: Line 201 calls `fdt_splice_mem_rsv_(fdt, re, 1, 0)`, so `oldn=1` and `newn=0`. Then `newn - oldn` is -1, and multiplying it by `sizeof(*p)` (size_t) converts it to a huge unsigned value. The code only works because that result is converted back to int. This is exactly the pattern signConversion is meant to report. The warning's notes point to the correct call site and argument values, so this is a valid new true positive, likely from the better path handling when combining values. It is somewhat benign in practice, which is why confidence is not high.