AI review of 2026-11-12_12-16-53-2f2568c15ea3-results.txt
PR:          #8974 https://github.com/cppcheck-opensource/cppcheck/pull/8974
Tested:      2f2568c15ea3fb3792448ac39e0e0850faccfc87
Merge base:  103143dcb6f67ba38d64e5eb390d77a9250790cb
Reviewed:    2026-11-13 21:08:12 UTC
Model:       claude-opus-5-5 (effort high)
Results:     6 reviewed of 6 in the report
Verdicts:    1 acceptable regression, 3 improvement, 2 regression
Tokens:      7237 input, 10690 cache read, 2138 cache write, 2099 output

The verdicts are written by AI and can be wrong.

---- 1 / 6 ----
Verdict:     IMPROVEMENT (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/e/emscripten/emscripten_6.0.5+dfsg+~1.41.5.orig.tar.xz
Result:      your emscripten-core-emscripten-1db5137/test/core/test_zero_multiplication.c:12:19: style: Argument '0*one' to function printf is always 0. Constant literal calculation disable/hide variable expression 'one'. [knownArgumentHiddenVariableExpression]
Explanation: `one = argc` holds an unknown integer, but ValueFlow gives it impossible values (argc is never negative). The old code skipped any variable that had values at all, so it missed this case. The PR now ignores impossible values, so `0 * one` is correctly reported as always 0, which is exactly what the check is meant to find. The file is an Emscripten test that multiplies by zero on purpose, but the warning is factually correct and matches the new test case for #15145. It is a true positive.

---- 2 / 6 ----
Verdict:     IMPROVEMENT (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/e/emscripten/emscripten_6.0.5+dfsg+~1.41.5.orig.tar.xz
Result:      your emscripten-core-emscripten-1db5137/test/core/test_zero_multiplication.c:13:19: style: Argument '0*-one' to function printf is always 0. It does not matter what value 'one' has. [knownArgument]
Explanation: `one` is `argc`, so its value is unknown. Cppcheck likely only knew impossible values for it (e.g. argc can't be negative). Before the PR, those values stopped the check. The PR now ignores impossible values, so the check runs. The argument `0 * -one` really is always 0 whatever `one` is, which is exactly what knownArgument is meant to report, and the message is accurate. The code is a deliberate emscripten test of zero multiplication, so users there may not care. Still, the warning is a correct true positive matching the intent of the PR and its new test.

---- 3 / 6 ----
Verdict:     IMPROVEMENT (medium confidence)
Package:     https://ftp.debian.org/debian/pool/main/e/emscripten/emscripten_6.0.5+dfsg+~1.41.5.orig.tar.xz
Result:      your emscripten-core-emscripten-1db5137/test/core/test_zero_multiplication.c:14:22: style: Argument '-one*0' to function printf is always 0. It does not matter what value 'one' has. [knownArgument]
Explanation: The new warning is correct: `-one * 0` with `int one = argc` is always 0, whatever `one` is. Before the PR, the check skipped this case because `one` (from `argc`) carried impossible values, so its value list was not empty. The PR now ignores impossible values when deciding whether the variable is unknown, which is what it intends. This file is an emscripten test that multiplies by zero on purpose, so the warning is not useful there, but it is accurate. It is a true positive, consistent with the new unit test for `0 * x`.

---- 4 / 6 ----
Verdict:     ACCEPTABLE REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/i/icecast2/icecast2_2.5.0.orig.tar.gz
Result:      main icecast-2.5.0/src/admin.c:1648:82: style: Argument 'cur->status>100' to function reportxml_helper_add_value_int is always 1. It does not matter what value 'status' has. [knownArgument]
     icecast-2.5.0/src/admin.c:1647:33: note: Assuming that condition 'cur->status>100' is not redundant
     icecast-2.5.0/src/admin.c:1648:82: note: Argument 'cur->status>100' to function reportxml_helper_add_value_int is always 1. It does not matter what value 'status' has.
Explanation: Inside `if (cur->status > 100)`, the argument `cur->status > 100` is always 1. This is a real bug: the code most likely meant to pass `cur->status`, so the status is always reported as 1. The PR now skips all comparison tokens (`%comp%`) in `checkKnownArgument`, so this true positive is no longer reported. That is a new false negative.

---- 5 / 6 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/libe/libedit/libedit_3.1-20260512.orig.tar.gz
Result:      your libedit-20260512-3.1/src/history.c:800:8: style: Argument '(max_size=1024)*sizeof(*ptr)' to function malloc is always 1024. It does not matter what value 'max_size' has. [knownArgument]
Explanation: The argument `(max_size = 1024) * sizeof(*ptr)` assigns 1024 to max_size and passes the result. It is a common idiom: initialize the variable and use it in the same expression. The value is not hidden by a constant calculation. The variable is being set, and its old value is irrelevant by design. The message 'It does not matter what value max_size has' is misleading and the warning is a false positive. It appears because the PR changed the vartok check from 'values().empty()' to 'no possible int values'. Before, max_size had a known/possible value from the assignment, so the check skipped it. Now the assignment subexpression inside the argument is treated as a hidden variable.

---- 6 / 6 ----
Verdict:     REGRESSION (high confidence)
Package:     https://ftp.debian.org/debian/pool/main/libe/libedit/libedit_3.1-20260512.orig.tar.gz
Result:      your libedit-20260512-3.1/src/history.c:851:8: style: Argument '(max_size=1024)*sizeof(*ptr)' to function malloc is always 1024. It does not matter what value 'max_size' has. [knownArgument]
Explanation: The argument `(max_size = 1024) * sizeof(*ptr)` is a deliberate idiom: it assigns `max_size` and allocates in one expression. The value of `max_size` before the call does not affect the result, because it is overwritten by the assignment. So the claim 'It does not matter what value max_size has' is meaningless here, and nothing is hidden or wrong in the code. The PR now ignores impossible values when looking for an 'unknown' variable. That lets the assigned variable `max_size` be picked up, so this new warning is a false positive.