AI review of 2026-10-16_09-49-59-023fb3b301de-results.txt PR: #8819 https://github.com/cppcheck-opensource/cppcheck/pull/8819 Tested: 023fb3b301de87dda15ed48c243c3c5a9db77311 Merge base: b2d83612a1d235901d70a77d25c21759014e4919 Reviewed: 2026-10-16 23:55:06 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 187 in the report (random sample), 54 not reviewed: valueFlowMaxIterations Verdicts: 23 improvement, 3 neutral, 21 regression, 3 unclear Tokens: 106413 input, 1766320 cache read, 441580 cache write, 37412 output The verdicts are written by AI and can be wrong. ---- 1 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/abiword/abiword_3.0.8+ds.orig.tar.xz Result: main AbiWord-release-3.0.8/src/af/ev/gtk/ev_UnixKeyboard.cpp:455:26: warning: Either the condition 'keyval>0xFF00' is redundant or the array 's_Table_NVK_0xfe[256]' is accessed at index 256, which is out of bounds. [arrayIndexOutOfBoundsCond] AbiWord-release-3.0.8/src/af/ev/gtk/ev_UnixKeyboard.cpp:452:13: note: Assuming that condition 'keyval>0xFF00' is not redundant AbiWord-release-3.0.8/src/af/ev/gtk/ev_UnixKeyboard.cpp:455:26: note: Array index out of bounds Explanation: At line 455, `keyval` is a guint known to satisfy `0xFE00 < keyval <= 0xFF00`, because the `keyval > 0xFF00` branch has already returned. When `keyval == 0xFF00`, the index `keyval - 0xFE00` is 256. That is one past the end of `s_Table_NVK_0xfe[256]`, so this is a real off-by-one out-of-bounds read. The PR now skips range-bound propagation through unsigned subtraction when it cannot prove there is no wrap-around. Here wrap-around is impossible because `keyval > 0xFE00`, but the PR's analysis does not see that, and the true positive is lost. ---- 2 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/a/angelscript/angelscript_2.38.0+ds.orig.tar.xz Result: your sdk/angelscript/source/as_array.h:532:12: style: Condition 'index==length-1' is always false [knownConditionTrueFalse] sdk/angelscript/source/as_compiler.cpp:15694:33: note: Calling function 'RemoveIndexUnordered', 1st argument '0' value is 0 sdk/angelscript/source/as_array.h:534:17: note: Assuming that condition 'index 0`) still allows `length == 1`. So the new 'always false' warning is a false positive. It likely comes from the changed infer/path or unsigned-arithmetic handling producing a wrong impossible value or wrong path combination. ---- 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:52: error: Shifting by a negative value is undefined behaviour [shiftNegative] Explanation: `AD7156_BurstWriteReg(int reg, char size, int txData)` computes `>> (8 * (size - 3))` on line 179. When a caller passes `size == 2`, that shift count is -8, which is undefined behaviour. The same holds for line 179:32 and for line 180, where `size - 4` gives -16. Line 178 is not flagged, and with `size == 2` its shift count is 0. That pattern points to `size == 2` coming from callers, which fits a burst write of a 16-bit AD7156 threshold or sensitivity register. The function always computes all four shifts, so a call with `size == 2` really executes negative shifts. The new warning therefore looks like a true positive that main missed. Confidence is medium because the call sites are not shown. ---- 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:180:32: error: Shifting by a negative value is undefined behaviour [shiftNegative] Explanation: Line 180 computes `0xFF << 8 * (size - 4)`. The new warnings appear on lines 179 and 180 but not on 178, which fits a caller passing `size == 2`. The AD7156 threshold and sensitivity registers are 16-bit, so burst writes with size 2 are expected. With size 2, the shift count here is 8*(2-4) = -16, and shifting by a negative count is undefined behaviour. The function's design causes this for any size below 4, so the new shiftNegative warning is very likely a true positive. The caller is not shown, so confidence is not high. ---- 5 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/coinor-dylp/coinor-dylp_1.10.4.orig.tar.gz Result: your DyLP-1.10.4/CoinUtils/src/CoinMpsIO.cpp:3747:44: warning: Either the condition 'value>=0.0' is redundant or log10() argument nr 1 can have invalid value. The value is 0 but the valid values are '4.94066e-324:'. [invalidFunctionArg] DyLP-1.10.4/CoinUtils/src/CoinMpsIO.cpp:3746:17: note: Assuming that condition 'value>=0.0' is not redundant DyLP-1.10.4/CoinUtils/src/CoinMpsIO.cpp:3747:44: note: Invalid argument Explanation: Inside `if (value >= 0.0)` the code calls `log10(value)`, and `value == 0.0` satisfies that condition. `log10(0)` is a pole error that returns -HUGE_VAL, and `static_cast` of -inf is undefined behaviour. Zero values are realistic when writing MPS data. The PR's new floating-point `>=`/`<=` condition handling now tracks the bound in the true branch, so Cppcheck detects this real defect. The new warning is a true positive and matches the PR's own `invalid_true_branch` test. ---- 6 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/d/dieharder/dieharder_3.31.1.4.orig.tar.gz Result: main libdieharder/rngav.c:96:11: warning: Shifting signed 32-bit value by 31 bits is undefined behaviour. See condition at line 95. [shiftTooManyBitsSigned] libdieharder/rngav.c:95:17: note: Assuming that condition 'i<96' is not redundant libdieharder/rngav.c:96:11: note: Shift Explanation: Line 96 runs in the branch where 64 <= i < 96, so `i-64` ranges over 0..31. When i == 95 the code evaluates `1<<31` on a signed 32-bit int, which is undefined behaviour in C. The removed shiftTooManyBitsSigned warning was therefore a true positive. The PR's new unsigned-wrap handling apparently drops the range bounds for the unsigned subtraction `i-64`, even though the else-branch guarantees i >= 64 and the subtraction cannot wrap. That loses a real finding. ---- 7 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/e/ettercap/ettercap_0.8.4.1.orig.tar.gz Result: main ettercap-0.8.4.1/src/ec_packet.c:69:12: style: Condition 'len+1' is always true [knownConditionTrueFalse] Explanation: `len` is `u_int`, so `len + 1` wraps to 0 when `len == UINT_MAX`. That is exactly the case the code guards against: a "negative" len such as -1 passed as `u_int`, which leads to the else branch with the error message. So the condition is not always true, and main's knownConditionTrueFalse warning was a false positive. The PR stops propagating lower bounds through unsigned arithmetic that may wrap, which correctly removes the warning. ---- 8 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/f/fcitx5-qt/fcitx5-qt_5.1.16.orig.tar.xz Result: your fcitx5-qt-5.1.16/qt5/widgetsaddons/qtkeytrans.cpp:678:9: warning: Either the condition 'count<(int)chars.size()-1' is redundant, otherwise there is negative array index -2. [negativeContainerIndex] fcitx5-qt-5.1.16/qt5/widgetsaddons/qtkeytrans.cpp:757:64: note: Calling function 'translateKeySym', 5th argument 'chars' value is size=0 fcitx5-qt-5.1.16/qt5/widgetsaddons/qtkeytrans.cpp:621:34: note: Assuming condition is false fcitx5-qt-5.1.16/qt5/widgetsaddons/qtkeytrans.cpp:677:15: note: Assuming that condition 'count<(int)chars.size()-1' is not redundant fcitx5-qt-5.1.16/qt5/widgetsaddons/qtkeytrans.cpp:678:9: note: Negative array index Explanation: Line 677 is a guard: `chars[count]` is written only when `count < chars.size()-1`. In the reported path `chars` is empty, so the bound is -1. The index could only be -2 if `count` were negative, but `count` is a character count that is 0 or set to 1. The warning works backwards from the guard to an impossible negative count, so it is a false positive. It is new with this PR, probably from the changed path handling in infer and condition parsing. ---- 9 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/garli/garli_2.1.orig.tar.gz Result: your garli-2.1-release/src/model.cpp:1888:27: warning: Either the condition 'v<=0.0' is redundant or std::log() argument nr 1 can have invalid value. The value is 0 but the valid values are '4.94066e-324:'. [invalidFunctionArg] garli-2.1-release/src/model.cpp:1913:40: note: Assuming that condition 'v<=0.0' is not redundant garli-2.1-release/src/model.cpp:1916:16: note: Calling function 'LnGamma', 1st argument 'v*0.5' value is 0.0 garli-2.1-release/src/model.cpp:1871:17: note: Assignment 'x=alp', assigned value is 0.0 garli-2.1-release/src/model.cpp:1888:27: note: Invalid argument Explanation: This is a new false positive. In PointChi2, the `v <= 0.0` case returns early, so `LnGamma(v*0.5)` is only reached with v > 0, never with 0.0. Even if `alp` were 0 inside LnGamma, the `x < 7` branch would run the `while (++z < 7.0)` loop and set x to at least 7 before `log(x)` on line 1888. The PR's new float-bound condition handling wrongly carries the true-branch value (0.0) past the early return. ---- 10 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/gmap/gmap_2025-07-31+ds.orig.tar.xz Result: main gmap-2025-07-31/src/stage3.c:9059:36: style: Condition 'genomejump<=0' is always false [knownConditionTrueFalse] gmap-2025-07-31/src/stage3.c:9057:38: note: Assignment 'genomejump=genomedp3-genomedp5+1', assigned value is greater than 0 gmap-2025-07-31/src/stage3.c:9059:36: note: Condition 'genomejump<=0' is always false Explanation: The removed warning is a false positive. `genomedp3` and `genomedp5` are genomic positions, probably the unsigned `Chrpos_T`, and both are changed by the peel functions. Main's note 'assigned value is greater than 0' comes from the unsigned minimum-value reasoning (min 0, plus 1). That reasoning ignores wrap-around: if `genomedp5 > genomedp3`, then `genomedp3 - genomedp5 + 1` wraps. Stored into the `int` `genomejump`, the result can be 0 or negative. The code explicitly guards this case ('This prevents cases like queryjump 0...'), so the check is not always false. The PR stops `minUnsignedValue` and range bounds from propagating through unsigned arithmetic that may wrap, which removes this false positive. ---- 11 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/g/gtkpod/gtkpod_2.1.5.orig.tar.gz Result: your gtkpod-2.1.5/libgtkpod/sha1.c:557:136: error: Array 'stupidblock->charblock[20]' accessed at index 62, which is out of bounds. [arrayIndexOutOfBounds] gtkpod-2.1.5/libgtkpod/sha1.c:460:52: note: Calling function 'little_endian', 2nd argument '16' value is 16 gtkpod-2.1.5/libgtkpod/sha1.c:555:18: note: Assuming that condition 'xcharblock[x*4+1..3]` for x up to 15, because it is called with blocks=16 (line 460). The declared `charblock` has only 20 bytes, so against the declared type, indices 61 to 63 are out of bounds. The call site at line 460 is not shown, though. In SHA1 code like this, the argument is often a 64-byte block cast to `hblock*`. In that case the access stays inside real memory and is only a type-punning issue, which users would treat as a false positive. If the argument really is a 20-byte hblock, it is a genuine overflow. The new warnings repeat the same pattern for the +1/+2/+3 offsets. Without seeing what is passed at line 460, I cannot tell whether they are true or false positives. ---- 12 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/g/gtkpod/gtkpod_2.1.5.orig.tar.gz Result: your gtkpod-2.1.5/libgtkpod/sha1.c:557:176: error: Array 'stupidblock->charblock[20]' accessed at index 63, which is out of bounds. [arrayIndexOutOfBounds] gtkpod-2.1.5/libgtkpod/sha1.c:460:52: note: Calling function 'little_endian', 2nd argument '16' value is 16 gtkpod-2.1.5/libgtkpod/sha1.c:555:18: note: Assuming that condition 'xcharblock[20]' accessed at index 61, which is out of bounds. [arrayIndexOutOfBounds] gtkpod-2.1.5/libgtkpod/sha1.c:460:52: note: Calling function 'little_endian', 2nd argument '16' value is 16 gtkpod-2.1.5/libgtkpod/sha1.c:555:18: note: Assuming that condition 'xdata)', assigned value is less than 2147483648 gtkpod-2.1.5/plugins/track_display/display_tracks.c:1244:22: note: Condition 'position==-1' is always false Explanation: `position` is a `guint` assigned from `GPOINTER_TO_INT(olp->data)`, which is an `(int)` value. When `old_position` is -1, the int -1 converts to UINT_MAX (0xFFFFFFFF). In `position == -1`, the -1 is also converted to unsigned, so the condition is true in exactly that case, which the code deliberately handles. The PR's new impossible range on the `(int)` cast (value < 2147483648) is carried across the implicit int-to-unsigned conversion, where it no longer holds. The new 'always false' warning is therefore a false positive. ---- 15 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/g/guile-3.0/guile-3.0_3.0.11.orig.tar.xz Result: your guile-3.0-3.0.11.orig/lib/log1p.c:516:21: warning: Either the condition 'x<=-1.0' is redundant or the array 'log_table[385]' is accessed at index -128, which is out of bounds. [negativeIndex] guile-3.0-3.0.11.orig/lib/log1p.c:28:9: note: Assuming that condition 'x<=-1.0' is not redundant guile-3.0-3.0.11.orig/lib/log1p.c:98:22: note: Assignment 'm=round(x*256.0)', assigned value is -256.0 guile-3.0-3.0.11.orig/lib/log1p.c:516:21: note: Negative array index Explanation: This is gnulib's log1p. When `x <= -1.0`, the function returns early (-HUGE_VAL or NaN). It also falls back to `log(1.0 + x)` when x < -0.5 or x > 1.0. So at line 516, x is in [-0.5, 1.0], `m = round(x*256)` is in [-128, 256], and `128 + (int)m` is in [0, 384], which fits `log_table[385]`. The new warning uses x = -1.0, a value from the true branch of `x<=-1.0`, which returns. The PR's new float `<=`/`>=` condition handling lets that value leak past the early return, so this new negativeIndex warning is a false positive. ---- 16 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/h/harp/harp_1.30+ds.orig.tar.gz Result: main harp-1.30+ds/udunits2/unitcore.c:285:16: style: Condition 'imonth>12' is always false [knownConditionTrueFalse] harp-1.30+ds/udunits2/unitcore.c:267:16: note: Assuming that condition 'julday<2299161' is not redundant harp-1.30+ds/udunits2/unitcore.c:273:23: note: Assignment 'ja=julday+1+ia-(int)(0.25*ia)', assigned value is 2299171 harp-1.30+ds/udunits2/unitcore.c:276:8: note: jb is assigned 'ja+1524' here. harp-1.30+ds/udunits2/unitcore.c:280:10: note: Assignment 'je=(int)((jb-jd)/30.6001)', assigned value is 11 harp-1.30+ds/udunits2/unitcore.c:284:17: note: Assignment 'imonth=je-1', assigned value is less than 11 harp-1.30+ds/udunits2/unitcore.c:285:16: note: Condition 'imonth>12' is always false Explanation: This is the standard Julian-day-to-calendar algorithm. `je` is computed as `(jb-jd)/30.6001` and normally ranges up to 14 or 15. So `imonth = je-1` can be 13 or more, and `if (imonth > 12) imonth -= 12;` is a necessary normalization. The removed warning was therefore a false positive. Its note chain is also inconsistent. It assumes `julday<2299161` is the case, yet takes the value 2299171 from the else branch assignment. It then turns a single value of 11 into 'less than 11'. This suggests values from incompatible paths or bounds were combined, which the PR's path and bound handling now prevents. The removed debug valueFlowMaxIterations message is not a concern either. ---- 17 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/i/ibm-3270/ibm-3270_4.3ga10.orig.tar.gz Result: main suite3270-4.3/x3270/CmeBSB.c:811:16: style: Condition 'menu_y>=0' is always true [knownConditionTrueFalse] suite3270-4.3/x3270/CmeBSB.c:801:23: note: Assignment 'menu_y=button_y+1', assigned value is greater than 0 suite3270-4.3/x3270/CmeBSB.c:811:16: note: Condition 'menu_y>=0' is always true Explanation: The same knownConditionTrueFalse warning for 'menu_y>=0' is still reported. Only the note changed: 'assigned value is greater than 0' became 'greater than -1'. `button_y` comes from `XtTranslateCoords` and is a screen coordinate that can be negative, so `menu_y = button_y + 1` can be negative unless `menu_y` is unsigned. The code's own `if (menu_y < 0)` check shows the author expects it can be. The warning is therefore probably a false positive either way. The new bound is slightly more consistent with the conclusion, but users get no real benefit or harm from the reworded note. ---- 18 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/i/ibm-3270/ibm-3270_4.3ga10.orig.tar.gz Result: your suite3270-4.3/x3270/CmeBSB.c:811:16: style: Condition 'menu_y>=0' is always true [knownConditionTrueFalse] suite3270-4.3/x3270/CmeBSB.c:801:23: note: Assignment 'menu_y=button_y+1', assigned value is greater than -1 suite3270-4.3/x3270/CmeBSB.c:811:16: note: Condition 'menu_y>=0' is always true Explanation: Both versions report the same `knownConditionTrueFalse` warning for `menu_y >= 0`. Only the supporting note changed: the value of `menu_y = button_y + 1` went from 'greater than 0' to 'greater than -1'. Both notes still justify the claim that the condition is always true. If `button_y` were unsigned, the old note would be slightly more precise. If it is signed (`Position`, filled by `XtTranslateCoords`), the warning is questionable in both versions. The type of `button_y` is not shown. Either way, what users see does not materially change. ---- 19 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/i/id-utils/id-utils_4.6.28.orig.tar.xz Result: your idutils-4.6.28-15da/gnulib-tests/test-intprops.c:315:3: style: Comparing expression of type 'signed int' against value 4294967294. Condition is always false. [compareValueOutOfTypeRangeError] Explanation: Line 315 expands to `ASSERT (result == ((-1) - (1u)))`, where `result` is an `int`. `(-1) - 1u` is an unsigned int, 4294967294u. In the `==` comparison, `result` is converted to unsigned, and after INT_SUBTRACT_WRAPV `result` holds -2, which converts to 4294967294u. So the condition is actually true at runtime, and 'always false' is wrong. The PR now truncates unsigned point arithmetic to 4294967294. The compareValueOutOfTypeRange check then compares that value against the signed int range without applying the usual arithmetic conversions. The result is a new false positive. ---- 20 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/k/khtml/khtml_5.103.0.orig.tar.xz Result: main khtml-5.103.0/src/misc/StringHash.h:252:33: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: `hash` is unsigned, so `hash + 1` wraps to 0 when hash == 0xFFFFFFFF. In that case `!(hash + 1)` is 1 and the shift gives 0x80000000. So `(!(hash + 1) << 31)` is not always zero. Main probably inferred that `hash + 1` is never 0, ignoring wrap-around (and maybe using the ASSERT(hash) guard). That made the operand look known to be 0, so the badBitmaskCheck was a false positive. The PR's unsigned wrap-around handling removes it, which is correct. The code exists exactly to handle the wrap case. ---- 21 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libo/liborigin2/liborigin2_20110117.orig.tar.gz Result: your liborigin2-20110117/Origin750Parser.h:74:160: warning: Undefined behaviour: float (1e+10) to integer conversion overflow. [floatConversionOverflow] liborigin2-20110117/Origin610Parser.cpp:519:20: note: Assuming that condition 'creationDate>=1e10' is not redundant liborigin2-20110117/Origin610Parser.cpp:521:49: note: Calling function 'doubleToPosixTime', 1st argument 'creationDate' value is 10000000000.0 liborigin2-20110117/Origin750Parser.h:74:160: note: float to integer conversion Explanation: The new float `>=` condition parsing creates a possible value of 1e10 for `creationDate` from the condition `creationDate>=1e10` at line 519. Line 519 is followed two lines later by the call to `doubleToPosixTime(creationDate)`, which fits an early-return guard (`if (creationDate >= 1e10) return;`). If so, 1e10 cannot reach the `(int)jdt` cast, and the true-branch value has leaked past the guard. The same pattern appears four times in this package, which also points to a systematic propagation bug rather than real defects. The caller source was not shown, so the guard shape is inferred; if the call were inside the true branch, the warning would be correct. ---- 22 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libo/liborigin2/liborigin2_20110117.orig.tar.gz Result: your liborigin2-20110117/Origin750Parser.h:74:160: warning: Undefined behaviour: float (1e+10) to integer conversion overflow. [floatConversionOverflow] liborigin2-20110117/Origin750Parser.cpp:2284:23: note: Assuming that condition 'modificationDate>=1e10' is not redundant liborigin2-20110117/Origin750Parser.cpp:2299:170: note: Calling function 'doubleToPosixTime', 1st argument 'modificationDate' value is 10000000000.0 liborigin2-20110117/Origin750Parser.h:74:160: note: float to integer conversion Explanation: The new warning comes from the PR's new parsing of float `>=` conditions. The value it reports, exactly 1e10, is the lower bound of the true branch of `modificationDate>=1e10`. In liborigin, a check like this is a guard: when the date is >= 1e10, the code skips or returns before calling `doubleToPosixTime`. So the call only runs with values below 1e10. Here, though, Cppcheck carries the true-branch bound past the guard and into the call. The 1e10 value therefore looks infeasible, and the same pattern appears in four parser files. This is most likely a new false positive caused by the incomplete float-condition handling. The 2284–2299 code is not shown, so the guard structure cannot be confirmed. ---- 23 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libo/liborigin2/liborigin2_20110117.orig.tar.gz Result: your liborigin2-20110117/Origin750Parser.h:74:160: warning: Undefined behaviour: float (1e+10) to integer conversion overflow. [floatConversionOverflow] liborigin2-20110117/Origin800Parser.cpp:530:20: note: Assuming that condition 'creationDate>=1e10' is not redundant liborigin2-20110117/Origin800Parser.cpp:532:49: note: Calling function 'doubleToPosixTime', 1st argument 'creationDate' value is 10000000000.0 liborigin2-20110117/Origin750Parser.h:74:160: note: float to integer conversion Explanation: The PR adds float >=/<= condition parsing to ConditionHandler. The new warning uses exactly the true-branch bound of 'creationDate>=1e10' (value 1e10). The call to doubleToPosixTime is two lines later, and liborigin's pattern is `if (creationDate >= 1e10) return ...;` followed by use of the date. So 1e10 cannot reach the (int)jdt conversion, and the guard exists precisely to exclude it. Cppcheck is leaking a true-branch value past an early return, which makes this a new false positive. Values between INT_MAX and 1e10 could still overflow (int)jdt, but the warning's reasoning about 1e10 is wrong. ---- 24 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libo/liborigin2/liborigin2_20110117.orig.tar.gz Result: your liborigin2-20110117/Origin750Parser.h:74:160: warning: Undefined behaviour: float (1e+10) to integer conversion overflow. [floatConversionOverflow] liborigin2-20110117/Origin810Parser.cpp:59:23: note: Assuming that condition 'modificationDate>=1e10' is not redundant liborigin2-20110117/Origin810Parser.cpp:74:170: note: Calling function 'doubleToPosixTime', 1st argument 'modificationDate' value is 10000000000.0 liborigin2-20110117/Origin750Parser.h:74:160: note: float to integer conversion Explanation: The new warning claims `modificationDate` is exactly 1e10 when it reaches `doubleToPosixTime`. That is the true-branch bound of the new float `>=` condition parsing this PR adds. The likely liborigin pattern is `if (modificationDate >= 1e10) return; ... doubleToPosixTime(modificationDate);`. The 610 parser case fits this: condition on line 519, call on 521. The parser source is not shown, so the early return is inferred, not confirmed. If it holds, a value >= 1e10 cannot reach the conversion, and the warning is a false positive caused by the true-branch value leaking past the guard. ---- 25 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libo/libotr/libotr_4.1.1.orig.tar.gz Result: main libotr-4.1.1/src/proto.c:923:18: style: Condition 'newsize>=1' is always true [knownConditionTrueFalse] libotr-4.1.1/src/proto.c:920:31: note: Assignment 'newsize=fraglen+1', assigned value is greater than 0 libotr-4.1.1/src/proto.c:923:18: note: Condition 'newsize>=1' is always true Explanation: The guard `start > 0 && end > 0 && start < end` means `end - start - 1` is an int in [0, INT_MAX-2]. Converted to size_t, `fraglen + 1` cannot wrap, so `newsize >= 1` really is always true. Main's reasoning ('greater than 0') was simplistic, but its conclusion was correct. The PR now treats any unsigned `+` as possibly wrapping and drops this warning. That removes a true positive, although the redundant check is a harmless defensive overflow guard, so some users may see it as noise. ---- 26 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/metaeuk/metaeuk_7-bba0d80+ds.orig.tar.xz Result: main metaeuk-7-bba0d80/lib/mmseqs/src/multihit/combinepvalperset.cpp:55:38: warning: Invalid lgamma() argument nr 1. The value is 0 but the valid values are '!0.0:'. [invalidFunctionArg] metaeuk-7-bba0d80/lib/mmseqs/src/multihit/combinepvalperset.cpp:54:25: note: Assignment 'i=0', assigned value is 0 metaeuk-7-bba0d80/lib/mmseqs/src/multihit/combinepvalperset.cpp:55:38: note: Invalid argument Explanation: The loop `for (size_t i = 0; i < maxOrfCount + 2; ++i) lGammaLookup[i] = lgamma(i);` always calls `lgamma(0)` on its first iteration. That is a pole error (it returns HUGE_VAL and may set errno), and Cppcheck's library config marks 0 as an invalid argument. The removed warning was correct. It most likely disappeared as a side effect of the PR's new unsigned wrap-around handling for `maxOrfCount + 2` in the loop condition, not because the code is safe. Losing this true positive is a regression. ---- 27 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/mruby/mruby_4.0.0.orig.tar.gz Result: your mruby-4.0.0/mrbgems/mruby-compiler/core/codegen.c:1724:20: style: Condition '(int)s->sp-n<0' is always false [knownConditionTrueFalse] mruby-4.0.0/mrbgems/mruby-compiler/core/codegen.c:2847:15: note: Assuming that condition 'n==0' is not redundant mruby-4.0.0/mrbgems/mruby-compiler/core/codegen.c:2845:7: note: Calling function 'pop_n_', 2nd argument 'n' value is 0 mruby-4.0.0/mrbgems/mruby-compiler/core/codegen.c:1724:20: note: Condition '(int)s->sp-n<0' is always false Explanation: `pop_n_` is a generic helper called with many values of `n` (`pop()`, `pop_n(n)`), so `(int)s->sp-n < 0` is a real underflow guard and can be true. Cppcheck reports it as always false only because it took `n==0` from one call site (line 2845, after a condition at 2847). The new path and infer handling turned that single-caller value into an 'always false' verdict for the whole function. This is a new false positive. ---- 28 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/mupen64plus-video-glide64mk2/mupen64plus-video-glide64mk2_2.6.0.orig.tar.gz Result: main mupen64plus-video-glide64mk2-src-2.6.0/src/Glide64/Combine.cpp:6358:69: style: Condition '(rdp.prim_color&0xFFFFFF00)-(rdp.env_color&0xFFFFFF00)==0' is always true [knownConditionTrueFalse] mupen64plus-video-glide64mk2-src-2.6.0/src/Glide64/Combine.cpp:6337:22: note: Assuming that condition 'rdp.prim_color!=0x000000ff' is not redundant mupen64plus-video-glide64mk2-src-2.6.0/src/Glide64/Combine.cpp:6358:69: note: Condition '(rdp.prim_color&0xFFFFFF00)-(rdp.env_color&0xFFFFFF00)==0' is always true Explanation: In the else-if branch `rdp.prim_color == 0xff`, so `rdp.prim_color & 0xFFFFFF00` is 0. The condition then reduces to `(unsigned)0 - (rdp.env_color & 0xFFFFFF00) == 0`. That is true only when the upper bits of `env_color` are zero. `env_color` is an unconstrained global struct member, so the condition is not always true. Main's warning was a false positive from treating unsigned subtraction as if it could not wrap. The PR stops propagating range bounds through possibly-wrapping unsigned arithmetic, which removes this false positive. ---- 29 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mupen64plus-video-glide64mk2/mupen64plus-video-glide64mk2_2.6.0.orig.tar.gz Result: your mupen64plus-video-glide64mk2-src-2.6.0/src/GlideHQ/tc-1.1+/s2tc/s2tc_algorithm.cpp:1205:36: error: Shifting by a negative value is undefined behaviour [shiftNegative] Explanation: `diffuse()` is an inline helper that reduces 8-bit channels to fewer bits. In s2tc it is called with small constant shifts: 3 and 2 for RGB565, and 4 for 4-bit alpha. For these values, `8 - 2*shift` is 2, 4 or 0, so it is never negative. The new shiftNegative warning is very likely a false positive. It probably comes from the PR's changed value inference for arithmetic and bounds. Main did not report it. ---- 30 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/n/nettle4/nettle4_4.0.orig.tar.gz Result: main nettle-4.0/serpent-decrypt.c:504:4: warning: Either the condition 'k>0' is redundant or the array 'ctx->keys[33][4]' is accessed at index 4294967293, which is out of bounds. [arrayIndexOutOfBoundsCond] nettle-4.0/serpent-decrypt.c:497:16: note: Assuming that condition 'k>0' is not redundant nettle-4.0/serpent-decrypt.c:499:4: note: Compound assignment '-=', assigned value is -7 nettle-4.0/serpent-decrypt.c:504:4: note: Array index out of bounds Explanation: `k` is unsigned, starts at 24, and only ever changes by `k -= 8` inside `while (k > 0)`. So it takes the values 24, 16, 8 and 0, and the largest index used is k+7 = 31, which is within `keys[33]`. Main assumed that `k > 0` allows k == 1, so `k -= 8` would give -7, which then wraps to a huge unsigned index. That value is unreachable, so the warning was a false positive. The PR stops propagating range bounds through unsigned arithmetic that may wrap, which removes this bogus result. ---- 31 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/oce/oce_0.18.3.orig.tar.gz Result: main oce-OCE-0.18.3/src/OSD/OSD_Path.cxx:683:18: style: Condition 'length==1' is always false [knownConditionTrueFalse] Explanation: `length` is a local int set once from `myDisk.Length()` and never modified afterwards (`P2DOS(Way)` does not touch it). The check at line 683 is nested inside `if (length != 1)`, so `length == 1` really is always false there. This is a genuine (and likely buggy) dead condition, so main's knownConditionTrueFalse warning was a true positive. The PR loses it, which is a regression. ---- 32 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/onednn/onednn_3.12.1+ds.orig.tar.xz Result: main uxlfoundation-oneDNN-c8c37fd/src/cpu/rv64/rvv_gemm_convolution.cpp:194:41: style: Condition 'n_elems>0' is always true [knownConditionTrueFalse] uxlfoundation-oneDNN-c8c37fd/src/cpu/rv64/rvv_gemm_convolution.cpp:193:64: note: Assignment 'n_elems=end_oc-start_oc+1', assigned value is greater than 0 uxlfoundation-oneDNN-c8c37fd/src/cpu/rv64/rvv_gemm_convolution.cpp:194:41: note: Condition 'n_elems>0' is always true Explanation: `n_elems = end_oc - start_oc + 1` is computed in `size_t`. If `end_oc == start_oc - 1`, the subtraction wraps and the result is 0. That can really happen here: when `balance211` gives a thread an empty range (`start == end`, with `start % oc != 0`), the loop still runs once with `first_os == last_os`. Then `start_oc = k%oc` and `end_oc = k%oc - 1`, so `n_elems` becomes 0. Main reasoned 'unsigned >= 0, plus 1, so > 0' and ignored wrap-around, so its 'always true' warning was a false positive. The PR's unsigned no-wrap check correctly drops that bound. ---- 33 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/openssl/openssl_4.0.3.orig.tar.gz Result: main openssl-4.0.3/crypto/ec/ecp_sm2p256.c:595:19: style: Condition '(num+1)==0' is always false [knownConditionTrueFalse] Explanation: `num` is a `size_t` with no known range, so `num + 1` wraps to 0 when `num == SIZE_MAX`. The check `(num + 1) == 0` is a deliberate overflow guard and can be true. Main wrongly reported it as always false, which is a false positive. The PR stops propagating range bounds through unsigned arithmetic that may wrap, and its test `full_range_wrap` (`u + 1u == 0u`) covers this exact pattern. Removing the warning is correct. ---- 34 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/openssl/openssl_4.0.3.orig.tar.gz Result: main openssl-4.0.3/crypto/o_str.c:307:13: style: Condition 'len==0' is always false [knownConditionTrueFalse] openssl-4.0.3/crypto/o_str.c:300:21: note: Assuming condition 'has_sep' is false openssl-4.0.3/crypto/o_str.c:300:29: note: Assignment 'len=has_sep?buflen*3:1+buflen*2', assigned value is greater than 0 openssl-4.0.3/crypto/o_str.c:302:16: note: Assuming condition is false openssl-4.0.3/crypto/o_str.c:307:13: note: Condition 'len==0' is always false Explanation: `len` is `has_sep ? buflen*3 : 1+buflen*2`. When `has_sep` is true and `buflen` is 0, `len` is 0, so `if (len == 0) ++len;` is reachable and needed. The removed warning only holds on the assumed `has_sep == false` path. It also relied on treating the unsigned `1+buflen*2` as "greater than 0", ignoring possible wrap-around. Reporting the condition as always false is a false positive. The PR's handling of unsigned arithmetic wrap and path-specific values removes it. ---- 35 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/openssl/openssl_4.0.3.orig.tar.gz Result: main openssl-4.0.3/providers/implementations/ciphers/ciphercommon_block.c:49:16: style: Condition '*inlen0' is not redundant openssl-4.0.3/providers/implementations/ciphers/ciphercommon_block.c:44:34: note: Assignment 'bufremain=blocksize-*buflen', assigned value is less than 1 openssl-4.0.3/providers/implementations/ciphers/ciphercommon_block.c:49:16: note: Condition '*inlen 0` and then carried bounds through the unsigned subtraction as if it were signed, ending up with `bufremain <= 0`. That made `*inlen < bufremain` look always false. In reality, whenever the caller passes less input than the free space in the block, the condition is true; this is the normal clamp before memcpy. The PR stops carrying range bounds through unsigned arithmetic that may wrap, so this false positive goes away. ---- 36 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/openssl/openssl_4.0.3.orig.tar.gz Result: main openssl-4.0.3/test/bio_base64_test.c:549:17: style: Condition 'padcase!=0' is always false [knownConditionTrueFalse] openssl-4.0.3/test/bio_base64_test.c:530:22: note: Calling function 'quotrem' returns !<=-1 openssl-4.0.3/test/bio_base64_test.c:534:11: note: Assuming condition is false openssl-4.0.3/test/bio_base64_test.c:675:11: note: Assuming that condition 'q!=0' is not redundant openssl-4.0.3/test/bio_base64_test.c:674:25: note: Calling function 'quotrem', 1st argument 'q' value is 0 openssl-4.0.3/test/bio_base64_test.c:549:17: note: Condition 'padcase!=0' is always false Explanation: `padcase` comes from `quotrem(variant, NPAD, &variant)`. That function computes `i - *q * m` in unsigned arithmetic, and the result is a real remainder that can be nonzero. The note chain also mixes values from different paths: an interprocedural call with `q` = 0 and 'returns !<=-1'. Concluding that 'padcase!=0' is always false is wrong; the code clearly expects padcase values 0..NPAD-1. The PR's handling of unsigned wrap-around and path compatibility removes this false positive, so removing it is an improvement. ---- 37 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/pcre3/pcre3_8.39.orig.tar.bz2 Result: main pcre-8.39/pcre_compile.c:9362:8: style: Condition 're==NULL' is always false [knownConditionTrueFalse] pcre-8.39/pcre_compile.c:9356:26: note: Assignment 'size=sizeof(struct real_pcre32)+(length+cd->names_found*cd->name_entry_size)*sizeof(unsigned int)', assigned value is greater than 63 pcre-8.39/pcre_compile.c:9361:6: note: Assignment 're=(struct real_pcre32*)(pcre32_malloc)(size)', assigned value is greater than 63 pcre-8.39/pcre_compile.c:9362:8: note: Condition 're==NULL' is always false Explanation: `re` is the return value of the allocator call `PUBL(malloc)(size)`, which can return NULL, so the check `re == NULL` is real error handling. Main apparently misread `(pcre32_malloc)(size)` as a cast of `size`. It then carried the lower bound of `size` ("greater than 63") over to the pointer and reported the NULL check as always false. That warning was a false positive. The PR stops lower bounds from passing through unsigned arithmetic that may wrap, such as the `size` computation, so the bogus bound is gone and the false positive disappears. ---- 38 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/pcre3/pcre3_8.39.orig.tar.bz2 Result: main pcre-8.39/pcre_study.c:1574:13: style: Condition 'extra==NULL' is always false [knownConditionTrueFalse] pcre-8.39/pcre_study.c:1572:11: note: Assignment 'extra=(pcre32_extra*)(pcre32_malloc)(sizeof(pcre32_extra)+sizeof(struct pcre_study_data))', assigned value is greater than 43 pcre-8.39/pcre_study.c:1574:13: note: Condition 'extra==NULL' is always false Explanation: `extra` is the result of a malloc call (`pcre32_malloc`). The function-pointer call is wrapped in parentheses, and Cppcheck mistook it for a cast. That led it to treat the pointer as non-NULL ('greater than 43'). malloc can return NULL, so the NULL check is valid and the 'always false' warning was a false positive. The PR removes it, which is good. It is most likely a side effect of the new impossible-value handling on casts and unsigned arithmetic. ---- 39 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/s3backer/s3backer_1.5.4.orig.tar.gz Result: your s3backer-1.5.4/hash.c:74:12: warning: Undefined behaviour: float (6.44246e+09) to integer conversion overflow. [floatConversionOverflow] s3backer-1.5.4/hash.c:72:17: note: Assuming that condition 'maxkeys>=(u_int)(4294967295*0.666666)-1' is not redundant s3backer-1.5.4/hash.c:74:12: note: float to integer conversion Explanation: Line 72 returns EINVAL when maxkeys >= (u_int)(UINT_MAX*0.666666)-1. On line 74, maxkeys is therefore below about 2.86e9, so maxkeys/0.666666 stays under UINT_MAX and the conversion to u_int cannot overflow. The reported value 6.44e9 is UINT_MAX/0.666666. That would require maxkeys to be near UINT_MAX, which is only possible in the branch that already returned. The new floatConversionOverflow warning is a false positive caused by the PR's condition/value-flow changes. ---- 40 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/sdrangel/sdrangel_7.27.2+dfsg.orig.tar.xz Result: your f4exb-sdrangel-97e9e21/plugins/channeltx/modchirpchat/chirpchatmodsource.cpp:238:48: warning: Shifting 32-bit value by 4294967292 bits is undefined behaviour. See condition at line 242. [shiftTooManyBits] f4exb-sdrangel-97e9e21/plugins/channeltx/modchirpchat/chirpchatmodsource.cpp:242:30: note: Assuming that condition 'm_chirpCount==2' is not redundant f4exb-sdrangel-97e9e21/plugins/channeltx/modchirpchat/chirpchatmodsource.cpp:238:48: note: Shift Explanation: In the SyncWord state, m_chirpCount goes 0 -> 1 -> 2. On the second chirp it is incremented to 2 and line 238 runs before the reset at line 242. With m_chirpCount unsigned, (1-m_chirpCount)*4 wraps to 0xFFFFFFFC = 4294967292. Shifting a 32-bit value by that amount is undefined behaviour. The PR now truncates unsigned arithmetic results to the correct width, so the wrapped shift count is computed correctly and this real bug is reported. That is a new true positive. ---- 41 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/simutrans/simutrans_124.5.orig.tar.gz Result: main simutrans-124.5/src/simutrans/world/simcity.cc:1319:20: style: Condition 'step_interval<1' is always false [knownConditionTrueFalse] simutrans-124.5/src/simutrans/world/simcity.cc:1318:29: note: Assignment 'step_interval=(2<<18u)/(buildings.get_count()*4+1)', assigned value is greater than 524287 simutrans-124.5/src/simutrans/world/simcity.cc:1319:20: note: Condition 'step_interval<1' is always false Explanation: `step_interval = (2<<18u) / (buildings.get_count()*4 + 1)` is 524288 divided by an unsigned denominator. The denominator can be large, and `get_count()*4+1` can even wrap, so the result can be 0. The guard `step_interval < 1` is therefore meaningful. The removed note claims the value is 'greater than 524287', which is wrong: the result is at most 524288, not at least. The PR stops propagating range bounds through unsigned arithmetic that may wrap, so this false knownConditionTrueFalse is gone. ---- 42 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/smenu/smenu_1.5.0.orig.tar.bz2 Result: main smenu-1.5.0/ctxopt.c:3326:17: style: Condition 'end>0' is always true [knownConditionTrueFalse] smenu-1.5.0/ctxopt.c:3310:13: note: Assuming that condition 'len>1' is not redundant smenu-1.5.0/ctxopt.c:3323:17: note: Assignment 'end=len-1', assigned value is greater than 0 smenu-1.5.0/ctxopt.c:3324:27: note: Assuming condition is true smenu-1.5.0/ctxopt.c:3326:17: note: Condition 'end>0' is always true Explanation: Inside `if (len > 1)`, `end = len - 1` is at least 1. `len` is `size_t`, so `len - 1` cannot wrap when `len > 1`. `end` is not modified before line 3326, so `end > 0` really is always true and the warning is a true positive (a redundant check). The PR's new unsigned-wrap handling apparently fails to prove that `len - 1` does not wrap here, drops the lower bound, and loses this valid knownConditionTrueFalse warning. ---- 43 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/strace/strace_7.2+ds.orig.tar.xz Result: main strace-7.2/src/dup.c:25:42: warning: Either the condition 'flags_arg>0' is redundant or the array 'tcp->u_arg[6]' is accessed at index 6, which is out of bounds. [arrayIndexOutOfBoundsCond] strace-7.2/src/dup.c:22:17: note: Assuming that condition 'flags_arg>0' is not redundant strace-7.2/src/dup.c:25:42: note: Array index out of bounds Explanation: `dup_123` is a static function. Its only callers pass `flags_arg` as -1 or 2, and the `flags_arg > 0` check excludes -1. So `tcp->u_arg[flags_arg]` is only ever indexed with 2. The condition `flags_arg > 0` gives no reason to assume the index can be 6. The removed `arrayIndexOutOfBoundsCond` was therefore a false positive, likely caused by a bad bound inferred from the condition. The PR's changes to path handling and bound inference no longer produce it. ---- 44 / 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:21772:32: style: Condition 'mlRep>=4' is always true [knownConditionTrueFalse] taisei-1.4.4/external/basis_universal/zstd/zstd.c:21769:114: 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:21772:32: note: Condition 'mlRep>=4' is always true Explanation: `mlRep` is set to `ZSTD_count_2segments(...) + 4`. The count function returns a match length bounded by the input buffer size, so the `size_t` addition cannot wrap in practice. That makes `mlRep >= 4` really always true, so main's warning was a valid (if minor) redundant-condition finding. The PR now treats any unsigned `+` whose operand range it cannot bound as possibly wrapping, and drops the lower-bound inference. As a result it loses this true positive and the similar ones in the same function. The wrap it guards against cannot happen here. ---- 45 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/t/texmacs/texmacs_2.1.4+ds.orig.tar.xz Result: your texmacs-2.1.4+ds/src/Edit/Interface/edit_keyboard.cpp:285:48: style: Condition 'i<=255' is always true [knownConditionTrueFalse] texmacs-2.1.4+ds/src/Edit/Interface/edit_keyboard.cpp:284:12: note: Assignment 'i((unsigned char)rew[0])', assigned value is less than 256 texmacs-2.1.4+ds/src/Edit/Interface/edit_keyboard.cpp:285:48: note: Condition 'i<=255' is always true Explanation: `i` is initialized from `(unsigned char)rew[0]`, so its value is always in 0..255. In `(i >= 128 && i <= 255)` the `i <= 255` part can never be false. The PR adds impossible-range values for integral casts, so Cppcheck now knows the cast result is at most 255 and reports the redundant check. The comparison is defensive but redundant, so the new knownConditionTrueFalse warning is a correct true positive. ---- 46 / 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` on `start_l_idx == -1`; only the supporting notes differ. The warning itself is plausibly correct. `left_diag` requires the two letters to differ, so `MAX(...) - 1` is at least 0. The else branch `MIN(...) + 1` is at least 1 unless `chess_get_letter_index` returns `SIZE_MAX`. Main's notes justify this only through the `left_diag == false` branch ("assigned value is greater than 0"), which is an incomplete explanation for an always-false claim. The new version's line is shown without its notes, so we cannot tell whether the explanation became more or less accurate. ---- 47 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/t/toxic/toxic_0.11.3.orig.tar.gz Result: your toxic-0.11.3/src/game_chess.c:515:21: style: Condition 'start_l_idx==-1' is always false [knownConditionTrueFalse] Explanation: Main and the PR report the same warning, 'start_l_idx==-1' is always false, at the same location. Only the attached note or error path differs, and we cannot see both versions of it. The warning itself is plausibly correct. `start_l_idx` is a `size_t` holding either `MAX(from,to)-1` or `MIN(from,to)+1`. In the `left_diag` branch the letters differ, so `MAX>=1` and the result never wraps to SIZE_MAX. In the other branch, `MIN+1` cannot equal SIZE_MAX. So the user still gets the same true-positive finding; at most the explanation path changed, and we cannot tell whether it got better or worse. ---- 48 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/u/undbx/undbx_0.21.orig.tar.gz Result: main undbx-undbx-0.21/dbxprogress.c:103:15: style: Condition 'n+1!=0' is always true [knownConditionTrueFalse] Explanation: `n` is an `unsigned int`, so `n + 1` wraps to 0 when n == UINT_MAX. That is clearly the intended sentinel here: the else branch on line 115 prints a blank prefix for that case. The condition 'n+1!=0' is not always true, so main's warning was a false positive. The PR stops propagating range bounds through unsigned arithmetic that may wrap, which removes this false positive. ---- 49 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/u/undbx/undbx_0.21.orig.tar.gz Result: main undbx-undbx-0.21/dbxprogress.c:112:15: style: Condition 'n+1!=0' is always true [knownConditionTrueFalse] Explanation: n is an unsigned int, so 'n + 1 != 0' is false when n == UINT_MAX. The code relies on exactly that wrap-around: callers pass -1 to mean 'no index', and the else branch prints a blank prefix in that case. The condition is therefore not always true, and the old warning was a false positive. The PR stops trusting ranges through unsigned arithmetic that may wrap, which removes this warning. ---- 50 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xdvik-ja/xdvik-ja_22.87.06+j1.42.orig.tar.xz Result: main xdvik-ja-22.87.06+j1.42/texk/xdvik/gui/pagesel.c:609:13: style: Condition 'idx<=0' is always false [knownConditionTrueFalse] xdvik-ja-22.87.06+j1.42/texk/xdvik/gui/pagesel.c:607:25: note: Calling function 'get_item_index' returns !<=0 xdvik-ja-22.87.06+j1.42/texk/xdvik/gui/pagesel.c:609:13: note: Condition 'idx<=0' is always false Explanation: `idx` comes from `get_item_index(widget, y)`. That function computes the list row from the mouse y coordinate: in the non-Motif branch roughly `(mouse_y - internal_height) / row_height + 1`, and in the Motif branch it calls `XmListYToPos`. The `Dimension` operands are promoted to int, so when the mouse is dragged above the top of the list the result can be 0 or negative. Handling exactly that drag-above-top case is the stated purpose of the callback. So `idx <= 0` is reachable, and main's 'always false' warning was a false positive. Its likely cause is that main treated the arithmetic as wrap-free or non-negative, which the PR's wrap-aware changes address. Removing the warning is correct.