AI review of 2026-11-11_03-39-21-38ea7990bd24-results.txt PR: #9004 https://github.com/cppcheck-opensource/cppcheck/pull/9004 Tested: 38ea7990bd249c85bc3ab964e61d9538b964dd0e Merge base: 4b66976df1dea47746a82c7bee12be7a322305d1 Reviewed: 2026-11-14 06:29:11 UTC Model: claude-opus-5-5 (effort high) Results: 10 reviewed of 10 in the report, the test is still running (400 analysed of 1000 requested packages) Verdicts: 2 neutral, 6 regression, 2 unclear Tokens: 12753 input, 81585 cache read, 9065 cache write, 9579 output The verdicts are written by AI and can be wrong. ---- 1 / 10 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.2.orig.tar.xz Result: your tr.bi:290:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_tr [valueFlowBailoutIncompleteVar] Explanation: tr.bi is an m4 template, and line 290 is the macro call `MF_DEFUN(tr, STRING, STRING input, STRING set1, STRING set2)`. The PR is meant to be performance-only (comma-search cache, enum-type cache, skipping unchanged functions), yet Cppcheck output changed. At the same location the PR now also adds an incompleteVar bailout for `BUILTIN_IDX_tr`/`dtype_string`, plus badBitmaskCheck and duplicateExpression warnings. That pattern suggests the macro-expanded code is now parsed or analysed differently, probably through the new comma-search cache in `setVarIdParseDeclaration`. The new 'Skipping function due to incomplete variable' message means Cppcheck understands this code worse than before. ---- 2 / 10 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.2.orig.tar.xz Result: your tr.bi:290:39: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable dtype_string [valueFlowBailoutIncompleteVar] Explanation: This is the m4 template line `MF_DEFUN(tr, STRING, STRING input, ...)`. Cppcheck cannot expand the macro, so `dtype_string` really is an unknown (incomplete) identifier, and the bailout message describes that correctly. Other new findings appear in this file at the same time: further bailouts and several style warnings on unrelated lines. That pattern suggests main never fully analysed this file, probably because of a timeout, and the PR's performance changes let the analysis finish. If so, Cppcheck does not understand the code worse; it simply reaches this debug message now. Debug output does not affect normal users, so the change is effectively neutral, though the exact cause is not certain. ---- 3 / 10 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.2.orig.tar.xz Result: your tr.bi:290:60: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Line 290 is an m4 template line, `MF_DEFUN(tr, STRING, ...)`. Column 60 lies inside the expansion of the MF_DEFUN macro, so the reported `x | x` with a zero operand comes from macro-generated code such as flag constants that both expand to 0. The user cannot fix this; it is a macro-configuration artifact, not a real redundant expression. The PR is meant to be a performance and refactoring change (caches, skipping functions in valueflow, alias search). New style warnings and new valueflow bailout debug messages suggest the analysis now behaves differently on this file, not that it understands the code better. Treating the warning as a new false positive is likely right, but the expanded macro text is not shown, so confidence is low. ---- 4 / 10 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.2.orig.tar.xz Result: your tr.bi:290:60: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Line 290 is an m4/macro line (`MF_DEFUN(tr, STRING, ...)`) with no visible `|` operator, so the `|` at column 60 must come from macro expansion. Generated `X | 0` style flag combinations are intentional, and a duplicateExpression warning there gives users nothing to act on. The PR is meant to be a performance refactor (caches, skipping functions), so it should not change diagnostics. These warnings appear together with new incomplete-variable bailouts for the same functions, which suggests tokenization or analysis changed unintentionally (possibly the new comma cache in setVarId). This looks like a new false positive or noise, but the macro definition is not shown, so confidence is low. ---- 5 / 10 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.2.orig.tar.xz Result: your tr.bi:296:60: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Line 296 is an m4 template line, `MF_DEFUN(sq, STRING, STRING input, STRING set1)`, which is not real C. Column 60 lies past the end of the line, so the warning points into macro-expanded or unknown code. The PR is meant to be a performance change (caching and skipping function analysis) and should not change results. Yet it adds 'Same expression on both sides' and 'one operand equal to zero' warnings on identical MF_DEFUN lines, together with new incomplete-variable bailouts. That pattern suggests a side effect of the tokenizer or valueflow changes, not a real `x | x`/`0 | x` bitmask bug in the source. This is very likely a new false positive. ---- 6 / 10 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.2.orig.tar.xz Result: your tr.bi:296:60: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Line 296 is an m4 template line, `MF_DEFUN(sq, STRING, STRING input, STRING set1)`. Column 60 is past the end of the visible text, so the warning points into an expansion of `MF_DEFUN` whose definition is not shown. The same location also gets a new badBitmaskCheck ('|' with a zero operand). That suggests the expansion produces something like `0|0` from flag macros, which would be intended configuration code rather than a real bug. The same warnings also appear at the other `MF_DEFUN` lines (290, 302), along with new debug bailouts. This suggests the PR mainly lets this file be analyzed further than before, for example by avoiding a crash or timeout, rather than changing the duplicateExpression check itself. Without the macro definition, it cannot be decided whether the warning is a meaningful true positive or macro-generated noise. ---- 7 / 10 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.2.orig.tar.xz Result: your tr.bi:302:60: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Line 302 is an m4 template line, `MF_DEFUN(dc, ...)`. Column 60 is past the end of the visible text, so the '|' comes from a macro expansion that is not shown. Cppcheck also reports that the same expression is on both sides of this '|'. That points to a generated expression such as `0|0` from the macro, not a real bitmask mistake by the author. The PR is meant to be a performance and caching change (enum type cache, comma search cache, skipped functions in valueflow). Its output should therefore not change. The new findings come together with new valueFlowBailoutIncompleteVar debug messages for the same functions, which suggests the analysis now behaves differently. A new style warning inside macro-expanded template code is most likely noise or a false positive. The macro definition is not shown, so confidence is low. ---- 8 / 10 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.2.orig.tar.xz Result: your tr.bi:302:60: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Line 302 is an m4 template invocation, `MF_DEFUN(dc, STRING, STRING input, STRING set1)`, and the source line is far shorter than column 60. So the warning must point at macro-expanded code. It is reported together with badBitmaskCheck ('|' with an operand equal to zero), which suggests the expansion yields something like `0|0` built from flag macros. Code generated by a macro like this is legitimate and not a real duplicate-expression bug. The pull request is meant to be a performance change (caches, skipping unchanged functions in ValueFlow iterations), so it should not change results. These new warnings, together with the new valueFlowConditionExpressions bailouts, point to changed analysis rather than a real defect being found. It is most likely a new false positive. ---- 9 / 10 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.2.orig.tar.xz Result: your tr.bi:504:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_tr [valueFlowBailoutIncompleteVar] Explanation: The new line is a debug bailout: valueFlowConditionExpressions skips the function because `BUILTIN_IDX_tr` is an incomplete variable, most likely an identifier from mailfromd's generated builtin code that Cppcheck cannot resolve. Every diff line for tr.bi is 'your'-only, including new style warnings on other lines. That suggests the file, or these functions, simply was not analysed or reported by main, not that Cppcheck now understands this code worse. Possible reasons include a timeout or changed iteration behaviour from the new skipped-function logic. The source is not shown and the PR has no direct link to incomplete-variable handling, so it cannot be decided whether this added bailout is a real loss of understanding or a side effect of the file now being analysed. ---- 10 / 10 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.2.orig.tar.xz Result: your tr.bi:707:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_tr [valueFlowBailoutIncompleteVar] Explanation: All diff lines for tr.bi are new, and none were removed. The most likely reason is that main did not finish this file (probably a timeout) and the PR's performance changes (caching, skipping unchanged functions) now let it complete. This bailout fires because `BUILTIN_IDX_tr` is an undefined macro/identifier in the .bi source, an incomplete variable that has nothing to do with the PR's logic. So the line does not show Cppcheck understanding the code worse. It is a side effect of the file now being analyzed, and debug output does not matter to users. No source code was shown, so this is an inference.