Fix #14769 FP unreadVariable with address in chained assignment of unused variable

[chrchr-github]

No description provided.

[dmcppcheck]

Test results for commit dddc7c8 (tools/test-my-pr.py, main compared to this PR):

Test: http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8926/
packages: 200
Differing warnings: 0 (+0 -0)
Timing: -1.6% (http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8926/2026-10-07_11-04-12-dddc7c83a0c5_timing.html)

_{Posted automatically by the cppcheck PR test runner. +N: warnings only with this PR, -N: warnings only with main. The AI review is written by Claude and can be wrong.}

[dmcppcheck]

@claude review

[claude]

This new condition doesn't look at tok at all. It is true whenever start is the target of an assignment that sits inside another =. When that happens, the code calls variables.read() on whatever variable doAssignment returned. For a = c = &i; that variable is i, the one whose address is taken. So i is now marked as read directly instead of through the alias. That hides the FP, but it may also hide real warnings. For example:

void f() { int i = 2; int *a, *c; a = c = &i; }

Here i is probably no longer reported, because *a is never used. Can you add a negative test like this one, or limit the check to the case where tok is an operand of the address-of operator? It would also help to add a test for a chained compound assignment such as x = y += 1;, since that path now goes through tok = tok->previous() as well.

[claude]

The fix works for the reported case, but the new chained-assignment condition is broad. It reads the variable that doAssignment returns, which in a = c = &i; is the variable whose address is taken (i), so it may cause false negatives. I've left an inline comment and suggested negative tests: an address-of chain whose result is never used, and x = y += 1;. I couldn't build cppcheck in this environment, so this comes from reading the code, not from running it.

🤖 Generated with Claude Code