AI review of 2026-10-15_14-27-51-3a9288bd0dc8-results.txt
PR:          #8940 https://github.com/cppcheck-opensource/cppcheck/pull/8940
Tested:      3a9288bd0dc850fe04c924ff4f4d80e0053629eb
Merge base:  b2d83612a1d235901d70a77d25c21759014e4919
Reviewed:    2026-10-15 19:59:50 UTC
Model:       claude-opus-5-5 (effort high)
Results:     2 reviewed of 2 in the report
Verdicts:    2 improvement
Tokens:      2652 input, 2271 cache read, 2271 cache write, 1505 output

The verdicts are written by AI and can be wrong.

---- 1 / 2 ----
Verdict:     IMPROVEMENT (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/d/ddcutil/ddcutil_2.2.7.orig.tar.gz
Result:      your rockowitz-ddcutil-d6050d6/src/util/edid.c:375:51: style: Comparing expression of type 'char' against value 128. Condition is always true. [compareValueOutOfTypeRangeError]
Explanation: `s` is a plain `char*`. With the default signed-char platform, `s[ndx]` can only hold -128..127, so `s[ndx] < 128` is indeed always true. The new warning is factually correct for the analyzed platform and is exactly what the PR (#11592) intends to report. It also points at a real portability quirk: the comparison only does something on platforms where char is unsigned, and the comment's intent ("value > 127") is better expressed by casting to unsigned char. One could argue the check is deliberately portable, which lowers confidence somewhat, but the message is accurate.

---- 2 / 2 ----
Verdict:     IMPROVEMENT (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/x/xalan/xalan_1.12.orig.tar.gz
Result:      your xalan_c-1.12/src/xalanc/XMLSupport/XalanUTF8Writer.hpp:250:26: style: Comparing expression of type 'char' against value 128. Condition is always true. [compareValueOutOfTypeRangeError]
Explanation: In XalanUTF8Writer, `value_type` is plain `char`. The PR now treats plain `char` as signed when the platform default is signed. There `theChar < 128` is always true: bytes 0x80–0xFF become negative and pass the assert. So the assert does not reject non-ASCII bytes as intended. That is a real, platform-accurate finding and matches the behaviour the PR added a test for. It is not a false positive, though the assert is meaningful on unsigned-char platforms.