AI review of 2026-10-14_06-45-12-7ae3a34445a5-results.txt PR: #8856 https://github.com/cppcheck-opensource/cppcheck/pull/8856 Tested: 7ae3a34445a52a3df2d776bba8a8602b504eaacd Merge base: 275f16a5223230cdcadf3f3f92bf9716138ac4fc Reviewed: 2026-10-15 05:22:20 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 70 in the report (random sample), 2 not reviewed: valueFlowMaxIterations Verdicts: 3 improvement, 15 neutral, 13 regression, 19 unclear Tokens: 233517 input, 114972 cache read, 15678 cache write, 39871 output The verdicts are written by AI and can be wrong. ---- 1 / 50 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:191:18: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable ENOENT [valueFlowBailoutIncompleteVar] Explanation: Every diagnostic for db.bi is new in this run, so the whole file was analyzed this time but apparently not on main (likely a timeout or a crash on main, not a change in how this line is understood). This message is a debug bailout: ENOENT comes from , which is not included, so Cppcheck correctly reports it as an incomplete variable. The PR's ternary/inference change has nothing to do with this function's `rc && rc != ENOENT` check. The message is an informational artifact and does not matter to users. ---- 2 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:211:30: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable MU_STREAM_READ [valueFlowBailoutIncompleteVar] Explanation: Every diagnostic for db.bi is reported only by 'your', and main reports nothing for this file. Main probably never finished analyzing the file (crash or timeout), and with the PR it now does. This bailout fires because MU_STREAM_READ comes from an unavailable mailutils header, so it is an incomplete variable. That has nothing to do with the PR's ternary/valueflow change and does not mean Cppcheck understands the code worse. It is simply part of the file now being processed. The odd location (a #define line in an m4 .bi file) supports that it is a side effect. On its own the debug line does not matter to users. ---- 3 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:272:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_db [valueFlowBailoutIncompleteVar] Explanation: db.bi is an m4-templated builtin file, not plain C; BUILTIN_IDX_db comes from an unexpanded macro, so Cppcheck cannot resolve it and bails out. The PR does not change how such variables are resolved. Every db.bi line in this diff is new and there are no 'main' lines, which suggests main produced no output for this file at all (perhaps a crash or abort). This bailout therefore looks like a side effect of the file now being analysed, not of worse code understanding. It is an expected debug message for unresolvable macro identifiers and has no real impact on users. ---- 4 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:272:45: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable dtype_number [valueFlowBailoutIncompleteVar] Explanation: This is a new valueFlowBailoutIncompleteVar debug message at db.bi:272. The file is an m4-processed .bi source that Cppcheck cannot really parse, because MF_DEFUN and the other macros are unexpanded. The PR changed how the condition operand of '?' is handled. Here that change caused many new messages, including bailouts and dubious style warnings such as "Same expression on both sides of '|'" on the macro-generated code. A new bailout debug message is not useful to users and shows the PR changed analysis of this unparseable code in a noisy way. ---- 5 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:272:66: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Line 272 is a blank line between m4 blocks in a `.bi` template, so the warning points into some macro expansion (MF_DEFUN, MF_DSEXP or the builtin registration) that is not shown. The paired duplicateExpression warning suggests something like `0 | 0` coming from macro-generated flags. That would be harmless generated code, not a real bug users would fix. Every result for this file is new ('your' only, including debug bailouts), which hints that main did not analyze it the same way at all. That is hard to link to the narrow `?:` / setTokenValue change. Without the expanded code, it cannot be decided whether this is a meaningful finding or noise. ---- 6 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:272:66: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Every diagnostic for db.bi appears only in 'your', including unrelated debug and style messages such as constParameterPointer at line 39. This suggests main did not finish analyzing this m4 template file, for example because of a crash or timeout, rather than the ?: inference change causing this specific warning. The warning is reported on a blank line (272) and points into some macro expansion (MF_DEFUN, BUILTIN_IDX_db, dtype_number) that is not shown. The paired badBitmaskCheck hints at something like '0 | 0' from macro-generated flags, which would be harmless noise. Without the expanded code, it cannot be determined whether the duplicate '|' operands are real. ---- 7 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:283:66: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: db.bi is an m4-preprocessed template, not real C. Cppcheck parses the MF_DEFUN/END macro text without the m4 expansion, so the code at line 283 is not meaningful C. The new 'Same expression on both sides of |' warning comes from cppcheck misreading these unexpanded macros. The PR also adds a burst of related noise in the same file: debug bailouts, badBitmaskCheck, legacyUninitvar and nullPointerRedundantCheck. This is a new false positive, so it is a regression. ---- 8 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:295:71: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Line 295 is just the `END` macro of the mailfromd .bi builtin DSL, so column 71 does not exist in the source. The '|' must come from macro-expanded registration code (likely `0 | 0` flags, which also explains the paired badBitmaskCheck warning). Duplicate constant flags in generated macro code are not a real defect users can act on. The whole file now emits a burst of new warnings and bailouts, which suggests this is noise from analysing macro-garbled code, not a genuine finding. A new false-positive style warning is a regression. ---- 9 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:338:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_db [valueFlowBailoutIncompleteVar] Explanation: Every diagnostic for db.bi appears only in the PR output, and main reports nothing for this file. Main most likely failed to finish db.bi (crash or timeout), and with the PR the file is now analyzed. This line is an ordinary valueFlowBailoutIncompleteVar debug message. It comes from the unexpanded mailfromd macros (MF_DEFUN/END and BUILTIN_IDX_db) in this .bi template file. It does not show that Cppcheck understands the code worse; it only appears because the file is processed at all. It does not matter to users either way. ---- 10 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:338:77: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Line 338 is just the mailfromd builtin-DSL token `END`. It is a macro whose expansion is not shown, so we cannot tell what `|` expression with a zero operand it produces at column 77. Every diff line for this file is new ('your' only), including clearly dubious ones like 'Uninitialized variable: null'. That suggests main produced no results for this file at all, rather than the PR changing this specific check. A zero operand in a macro-generated flag expression is usually intentional and not actionable. Still, without the macro definition we cannot say whether the warning is a real finding or a false positive. ---- 11 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:338:77: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Line 338 is just the `END` macro of mailfromd's .bi DSL, so the `|` expression at column 77 comes from macro expansion that is not shown. Many warnings appeared together for this file, including new valueFlowBailoutIncompleteVar debug messages. That suggests the file is now analysed where it was not before (main may have crashed or timed out), rather than this PR changing one specific check. Without the macro expansion, it cannot be decided whether 'X | X' is a real duplicate or harmless macro-generated code. ---- 12 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:384:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_db [valueFlowBailoutIncompleteVar] Explanation: This is a debug bailout: ValueFlow skips a function because the macro-generated identifier BUILTIN_IDX_db is unknown. That comes from the unexpanded MF_DEFUN/END macros in this .bi file, not from the ternary-handling change in the PR. Every db.bi line in the diff is new, so main apparently produced no output for this file at all (perhaps it crashed or timed out, which cannot be checked here). This message shows up only because the file is now analyzed, and it reflects normal incomplete-variable behaviour, not worse code understanding. ---- 13 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:384:71: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Line 384 is the `END` marker of a mailfromd `.bi` builtin definition. The real code comes from a generated C file whose `#line` directives point back into `db.bi`. That generated registration code apparently ORs flag values that are all zero (e.g. `0 | 0`). Cppcheck is technically right that the `|` is redundant, but in generated code it is intentional and the warning is just noise. The PR's valueflow change (the `?:` inference and the conditional `setTokenValue` change) has no direct connection to badBitmaskCheck. The same new warnings and bailouts appear for the whole file, which suggests main failed or aborted on this file rather than that this warning was gained through better understanding. The source shown does not let me tell whether this is a gain or noise, so the verdict is unclear. ---- 14 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:384:71: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Line 384 is just the `END` macro of mailfromd's `.bi` builtin DSL, and we can't see what it expands to. Every finding for db.bi is new, including many debug bailouts, which suggests main did not finish analyzing this file and the PR somehow lets it complete; it is not a targeted change to this check. The new warning sits at the same spot as a 'one operand equal to zero' badBitmaskCheck, so the expansion probably contains something like flag macros that both evaluate to the same value (e.g. `0|0`). That would be harmless generated code and a noisy or false report. Without the macro definition I can't tell whether this is a real defect. ---- 15 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:43:10: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable S_IRUSR [valueFlowBailoutIncompleteVar] Explanation: Every diff line for db.bi is a 'your' line and there are no 'main' lines at all. That suggests main produced no results for this file (likely a timeout or crash), and the patched version now analyzes it fully. This debug message is the usual valueFlowBailoutIncompleteVar note because S_IRUSR comes from a system header that was not included. It does not mean Cppcheck understands strtomode() any worse; it only shows up because the file is now being analyzed. By itself the message has no value for users either way. ---- 16 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:468:70: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Line 468 in the shown db.bi is blank. The warning column (70) points into code produced by macro or m4 expansion of the MF_DEFUN/builtin-registration machinery, which is not shown. Every diff line for this file is new, including many debug bailouts. That suggests main did not finish analysing this file at all, rather than the PR changing ternary inference for this specific expression. Without the expanded code (probably something like a flags expression `X | 0`) it is impossible to tell whether the redundant-'|' report is a genuine issue or generated-code noise. ---- 17 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:491:14: warning: Identical inner 'if' condition is always true. [identicalInnerCondition] db.bi:487:6: note: outer condition: rc db.bi:491:14: note: identical inner condition: rc Explanation: The code has `if (rc) { if (rc == MU_ERR_NOENT) {...} else if (rc) {...} }`. The inner `else if (rc)` sits inside the outer `if (rc)`, so it is always true. The warning is therefore a true positive. Every diff line for this file is new, which suggests main did not finish analyzing db.bi and the PR now gets through it. The reported line and column numbers look shifted, probably because of macro expansion in the .bi file. The finding itself still matches the source. ---- 18 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:509:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_db [valueFlowBailoutIncompleteVar] Explanation: Every diff line for db.bi is a 'your' line, and there are no 'main' lines. So main most likely produced no output for this file at all, for example because of a crash or timeout, and the PR run analysed it fully. This debug message comes from the unexpanded mailfromd macro (MF_RETURN, using BUILTIN_IDX_db). That macro is unknown to Cppcheck whether or not the PR is applied, so the message does not show worse understanding. It appears only because the file is now analysed, and debug bailouts do not affect users either way. ---- 19 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:509:68: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Line 509 is just `MF_RETURN(n);`, and column 68 does not exist on that line, so the reported '|' comes from an MF_RETURN macro expansion that is not shown. Every diff line for db.bi is new, which suggests main produced no output for this file at all, perhaps because of a crash or bailout, rather than this PR's narrow ?: inference change creating the warning. The same pair of '|' warnings (zero operand and identical operands) appears on every MF_RETURN line. That pattern looks like macro-generated noise, such as an unknown type constant OR'd with 0, not a real bug. Without the macro definition, I can't tell whether it is a true or false positive. ---- 20 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:509:68: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Line 509 is just `MF_RETURN(n);`, but the warning points at column 68, past the end of the visible text. So it comes from inside the expansion of the MF_RETURN macro, whose definition is not shown. The companion badBitmaskCheck message at the same spot says one operand is zero, which suggests something like `0 | 0` produced by macro defaults. That would be intentional macro boilerplate, not a real coding mistake. The same pair of warnings appears at every MF_RETURN/MF_DEFUN site in the file. Main reported nothing for this file, possibly because its analysis did not finish. With the PR, the file is analyzed and produces many new bailouts and macro-artifact style warnings. This particular warning is most likely noise for users, though without the macro definition this cannot be confirmed. ---- 21 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:534:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_db [valueFlowBailoutIncompleteVar] Explanation: Every diff line for db.bi is new ('your' only), so main apparently produced no output for this file at all (crash, timeout or similar), while the PR version analyzes it. This line is a generic valueFlowBailoutIncompleteVar debug message about the unknown macro or enum BUILTIN_IDX_db, which the MF_RETURN macro presumably expands to. It has nothing to do with the PR's change to ternary inference. It shows up only because the file is now processed. It is not a user-facing finding and does not show worse understanding of the code. ---- 22 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:534:66: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Line 534 is just `MF_RETURN(1);`. Column 66 lies far past the end of that short line, so the warning comes from macro-expanded code that is not shown, probably a flag combination built from MF_RETURN/MF_DEFUN expansions. Every diff line for db.bi is new, including many valueFlowBailoutIncompleteVar debug messages. That suggests the whole file was analyzed (or reached) differently, not that this specific check changed because of the ?: inference change. Without the macro definitions, it cannot be told whether the '|' really has identical operands, as a real but harmless redundancy, or is a false positive. ---- 23 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:549:70: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Line 549 is just `MF_RETURN_OBSTACK();`, but the warning points at column 70, far past the end of that text. So the '|' expression comes from a macro expansion whose definition is not shown. db.bi is an m4-style builtin source (MF_DEFUN, END), not plain C. Cppcheck sees many incomplete variables here (BUILTIN_IDX_db, dtype_number), so a '|' with a zero operand and identical sides is likely an artifact of how the macros were configured, not a real bug. Main reported nothing for this file and the PR reports many new findings, which suggests main failed on this file and the PR now gets further. That is not clearly good or bad in itself. Without the macro definitions, I cannot tell whether this specific badBitmaskCheck is real. ---- 24 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:549:70: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Line 549 is just the `MF_RETURN_OBSTACK()` macro, a mailfromd .bi builtin-definition macro. The same `|` duplicate and `badBitmaskCheck` warnings now appear at nearly every macro-generated return or definition line in the file. That pattern points to macro-expanded flag expressions where both operands happen to be 0 in this configuration, probably because the PR now gives `?:` results new values. The user cannot change anything in the source here, so this looks like a macro-expansion false positive rather than a real bug. The macro definitions are not shown, though, so confidence is low. ---- 25 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:576:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_db [valueFlowBailoutIncompleteVar] Explanation: Every diff line for db.bi is new and there are no main lines at all. Main most likely produced no output for this file (perhaps it crashed or timed out), and with the PR the file is now analyzed. This bailout comes from the MF_RETURN_OBSTACK macro using BUILTIN_IDX_db, which is not defined because the generated headers are not available. That is an ordinary incomplete-variable bailout, unrelated to the ternary or condition logic the PR changes. It only appears because the file now gets analyzed; it does not show Cppcheck understanding this code better or worse. ---- 26 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:576:75: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Every diff line for db.bi is new, including the debug bailouts for the whole file. That suggests main never finished analysing this file (crash or timeout), not that the PR's ternary/valueflow change produced this specific warning. Line 576 is only the macro call `MF_RETURN_OBSTACK()`. The warning is about its expansion, which is not shown. It is also paired with 'Same expression on both sides of |' and appears at every MF_RETURN-style macro site, so it looks like macro-generated noise rather than a real bug. Without the expansion we cannot tell whether it is a true or false positive. ---- 27 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:656:104: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable dbname [valueFlowBailoutIncompleteVar] Explanation: This is a valueFlowBailoutIncompleteVar debug message saying `dbname` is an incomplete variable. The reported column (104) does not fit the shown line `time(&now);`, which points to generated or macro-expanded code in this m4-processed .bi file. The PR changes ternary condition inference and conditional value marking, not incomplete-variable detection. Every diff line for db.bi is new and none were removed, so main most likely produced no output for this file at all (for example a timeout or abort), and the PR version now completes it. In that case this message is a side effect of the file being analyzed, not a sign that Cppcheck understands the code worse. It does not affect users' warnings. ---- 28 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:782:104: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable dbname [valueFlowBailoutIncompleteVar] Explanation: Every diagnostic for db.bi is new in the PR run, including unrelated checks such as constParameterPointer at line 39. So main most likely produced no output for this file (crash, timeout or abort), and the PR now gets through it. This valueFlowBailoutIncompleteVar line is a side effect of the file now being analyzed. It does not come from the changed ternary/condition inference logic. It also does not show that Cppcheck understands do_greylist_ct worse: 'dbname' is a struct member reached through greylist_format, so a separate weakness is flagged as incomplete. A debug-only message like this does not affect users either way. ---- 29 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:879:104: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable dbname [valueFlowBailoutIncompleteVar] Explanation: This is a debug bailout about the incomplete variable `dbname`, which comes from a macro-expanded `greylist_format->dbname` that Cppcheck cannot resolve. That is a property of the code, not of the PR's ternary-inference change. Every diff line for db.bi is 'your' only, with no 'main' lines. So main most likely produced no output for this file at all (crash, timeout or abort), and the PR version now analyzes it. The bailout therefore appears because the file is now processed, not because Cppcheck understands the code worse. On its own it does not matter to users. ---- 30 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:926:82: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: The new badBitmaskCheck points to column 82 of a comment line. The real code is generated by the MF_DEFUN macro in a .bi file, which is not normal C. The flagged '|' with a zero operand is probably a flag combination produced by the macro expansion (e.g. type flags OR'd with 0), not code the user wrote. The matching duplicateExpression and odd locations elsewhere in this file point to the same macro-expansion noise. Every diff line for db.bi is new, which suggests the PR changed how far analysis gets on this file rather than finding a real bug. A redundant '|' in macro-generated code is not useful to report, so this looks like a new false positive. ---- 31 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:926:82: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Line 926 is a comment, so this warning comes from mailfromd's generated C code, mapped back to db.bi through #line directives. The expression that has the same operand on both sides of '|' is not visible here. It is probably something like a `0 | 0` produced by the MF_DEFUN macros, since a badBitmaskCheck appears at the same spot. Every line for this file, including the debug bailouts, is new in 'your'. That suggests main did not finish analyzing the file at all, rather than the PR changing this specific check. Without the expanded code, it is impossible to tell whether this is a real issue or harmless noise from macro-generated code. ---- 32 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:932:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_db [valueFlowBailoutIncompleteVar] Explanation: Every diff line for db.bi is a 'your' line, which suggests main produced no output for this file, probably because it crashed or timed out. The PR's file is now fully analyzed, so all its normal messages appear. This bailout comes from the unknown macro-generated identifier BUILTIN_IDX_db in the MF_DEFUN expansion. It has nothing to do with the PR's change to ternary inference, so it does not mean Cppcheck understands the code worse. It is just a side effect of the file now producing output. ---- 33 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:932:70: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: This file is a mailfromd .bi source that is normally run through a preprocessor first. Every result for it, including many debug bailouts, appears only in the PR run. That suggests main produced no output for the file at all, perhaps from a crash or timeout, rather than this specific check changing. The warning points to line 932, column 70, but line 932 is just `{`. The '|' with a zero operand must therefore come from code generated by the MF_DEFUN macro, which is not shown. We cannot tell whether that `x | 0` is real redundant code or an artifact of how Cppcheck parses this unpreprocessed file. ---- 34 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:932:70: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Every diff line for db.bi is new, including warnings unrelated to the ternary/valueflow change, such as constParameterPointer at line 39. This suggests main produced no output for this file at all, probably because analysis aborted or timed out, rather than the PR changing this specific check. The flagged location, line 932 column 70, is the '{' after an MF_DEFUN macro. So the '|' expression comes from macro expansion that is not shown. The paired badBitmaskCheck says one operand is zero, so the expansion likely ORs flag macros that are both 0. That may be a harmless macro artifact rather than a real duplicate expression, but the expanded code is not visible, so it cannot be judged. ---- 35 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:938:14: warning:inconclusive: Either the condition 'fmt!=NULL' is redundant or there is possible null pointer dereference: fmt. [nullPointerRedundantCheck] db.bi:935:13: note: Assuming that condition 'fmt!=NULL' is not redundant db.bi:938:14: note: Null pointer dereference Explanation: `MF_ASSERT(fmt != NULL, ...)` is mailfromd's assertion macro. When the condition fails it throws a runtime exception (non-returning `env_throw`/longjmp), so `fmt->dbname` is only reached when `fmt` is non-null. The new nullPointerRedundantCheck is therefore most likely a false positive. Cppcheck probably does not see the macro expansion as non-returning, and the odd line mapping (the warning points at `{` and `END`) also suggests it misreads this .bi file. Many other new messages for this file also appear only in 'your', including bailouts and badBitmaskCheck/duplicateExpression on macro code. That suggests the file is now analyzed differently, possibly not because of the ?: inference change itself. Either way, the added warning is not useful to users. ---- 36 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:942:82: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Every diff line for db.bi is new, including warnings and debug messages unrelated to the PR, such as constParameterPointer at line 39 and many bailout messages. This suggests main produced no output for this generated/preprocessed file at all, perhaps because of a crash or timeout. The PR's own logic (inferring conditions for the LHS of '?' only, and the setTokenValue tweak) has nothing to do with badBitmaskCheck. The warning points at code generated by the MF_DEFUN/MF_ASSERT macros, where some operand of '|' is zero; the same spot also gets a duplicateExpression warning. That is probably intentional macro-generated flag code, so the warning is likely noise. Without the expanded code, it is impossible to tell whether it is a meaningful true positive or a false positive, or why it newly appears. ---- 37 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:942:82: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Line 942 is just `_("no such db format: %s"), fmtid);` and has no '|' at all; column 82 does not exist on it. The warning must therefore come from code produced by expanding the MF_DEFUN/MF_ASSERT machinery. The same badBitmaskCheck/duplicateExpression pair appears at every MF_DEFUN line, which suggests something like `0|0` in generated flags. That is not actionable for users and is most likely a false positive. Main reported nothing for db.bi, perhaps because analysis of the file aborted or timed out, so the cause of the change is not certain. Even so, this specific new warning looks like noise. ---- 38 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:948:34: warning:inconclusive: Either the condition 'fmt!=NULL' is redundant or there is possible null pointer dereference: fmt. [nullPointerRedundantCheck] db.bi:945:13: note: Assuming that condition 'fmt!=NULL' is not redundant db.bi:948:34: note: Null pointer dereference Explanation: The new warning is very likely a false positive. `MF_ASSERT(fmt != NULL, mfe_not_found, ...)` is mailfromd's assertion macro: if the condition fails it raises an exception and leaves the builtin. So `fmt` cannot be NULL when it is dereferenced afterwards. Cppcheck cannot see that the macro exits, because `db.bi` is an m4-style builtin source whose macros are not resolved. The reported line and column do not match the shown source: the note points at `END` and the warning at `{`. That suggests Cppcheck is analysing mangled or misunderstood code. Main reported nothing for this file, and the PR added a batch of other suspect findings with it, such as 'Same expression on both sides of |' and 'Uninitialized variable: null'. Together this points to new noise rather than real bugs. ---- 39 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:952:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_db [valueFlowBailoutIncompleteVar] Explanation: Every diff line for db.bi is new, which suggests main produced no output for this file at all, probably because it timed out or crashed. The PR changes ternary handling in valueFlowInferCondition and setTokenValue. This message is unrelated to that: the bailout comes from the unexpanded MF_ASSERT/MF_DEFUN macros, which leave BUILTIN_IDX_db as an incomplete variable. It is a generic debug message that appears simply because the file is now analyzed. It says nothing about better or worse understanding of the code, so it has no direct effect on users. ---- 40 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:952:87: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Line 952 is the last line of an `MF_ASSERT(...)` macro call inside an `MF_DEFUN` block in a .bi file. The reported column (87) is past the end of the source line, so the warning comes from macro-expanded code we cannot see. The PR adds this warning together with dozens of other new warnings and debug lines for the whole file. That suggests the file is now analyzed differently overall, rather than one specific valueflow fix. Without the macro definitions it is impossible to tell whether a real `x | 0` exists, or whether this is noise in generated code. ---- 41 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:952:87: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Every diff line for db.bi is a 'your' line, including many unrelated debug bailouts. This suggests main produced no output for this file at all (likely a crash or timeout), rather than the PR changing this specific check. The PR only changes ternary-condition inference and has no obvious link to a duplicateExpression on '|'. The column (87) does not exist in the shown line 952, so the warning comes from expansion of the MF_DEFUN/MF_ASSERT macros, whose definitions are not shown. It is probably something like a flags expression of the form 0|0. That is typical macro-generated noise rather than a real bug, but without the macro expansion and the reason main was silent, the verdict cannot be determined reliably. ---- 42 / 50 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:962:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_db [valueFlowBailoutIncompleteVar] Explanation: Every diff line for db.bi is a 'your' line, so main most likely produced no output for this file at all (probably a crash or timeout), and the PR version now completes the analysis. This valueFlowBailoutIncompleteVar message comes from the unexpanded MF_DEFUN/MF_ASSERT macros referencing the unknown identifier BUILTIN_IDX_db. It appears because the file is now analyzed, not because Cppcheck understands the code worse. On its own, this debug message does not matter to users. ---- 43 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:962:92: style: Same expression on both sides of '|'. [duplicateExpression] Explanation: Every diff line for db.bi is new, including debug bailouts unrelated to this PR. That suggests main produced no output for this file at all, probably because it crashed or timed out, and the PR branch now analyses it. db.bi is an m4-style builtin source full of unexpanded macros (MF_DEFUN, MF_ASSERT, _()). The reported column 92 does not exist in the shown text; it points into a macro expansion of MF_ASSERT/MF_DEFUN that is not visible. Without that expansion, it cannot be told whether the '|' really has identical operands (e.g. two zero flags from a macro) or whether this is noise from misunderstood macro code. The warning is likely low-value, but there is not enough information to decide. ---- 44 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz Result: your db.bi:968:34: warning:inconclusive: Either the condition 'fmt!=NULL' is redundant or there is possible null pointer dereference: fmt. [nullPointerRedundantCheck] db.bi:965:13: note: Assuming that condition 'fmt!=NULL' is not redundant db.bi:968:34: note: Null pointer dereference Explanation: In mailfromd, `MF_ASSERT(fmt != NULL, ...)` raises a runtime exception (it throws via longjmp) when the condition is false, so it does not return. Every dereference of `fmt` after it is guarded, and the 'fmt!=NULL is redundant or possible null dereference' warning is a false positive. It is one of many new warnings in db.bi, including suspicious `badBitmaskCheck`, `duplicateExpression` and `legacyUninitvar` ones, which suggests the PR changed how this macro-heavy file is analyzed and added noise rather than real findings. ---- 45 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/n/newlib/newlib_4.6.0.20260123.orig.tar.xz Result: your newlib-4.6.0.20260123/newlib/libc/time/gmtime_r.c:88:46: warning: Either the condition 'days>=0' is redundant or there is signed integer overflow for expression 'era*400'. [integerOverflowCond] newlib-4.6.0.20260123/newlib/libc/time/gmtime_r.c:80:15: note: Assuming that condition 'days>=0' is not redundant newlib-4.6.0.20260123/newlib/libc/time/gmtime_r.c:80:15: note: Assuming condition 'days>=0' is false newlib-4.6.0.20260123/newlib/libc/time/gmtime_r.c:80:56: note: Assignment 'era=(days>=0?days:days-(146097L-1))/146097L', assigned value is -1 newlib-4.6.0.20260123/newlib/libc/time/gmtime_r.c:88:46: note: Integer overflow Explanation: The new warning claims that `era*400` overflows when `days>=0` is false, and its own note gives `era = -1`. Then `-1 * 400 = -400`, which is far from overflowing `int`. When `days` is negative, the ternary picks `days - 146096` before dividing, so `era` is just a small negative era index. Whether `days>=0` is true has nothing to do with overflow. The PR changed how values are inferred through `?:`, and that appears to have produced a bogus value or bound for `era`. This is a new false positive. ---- 46 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/o/opencv/opencv_5.0.0+dfsg.orig.tar.xz Result: your opencv-5.0.0/modules/features/src/sift.dispatch.cpp:173:57: warning: Shifting 32-bit value by 128 bits is undefined behaviour. See condition at line 172. [shiftTooManyBits] opencv-5.0.0/modules/features/src/sift.dispatch.cpp:172:21: note: Assuming that condition 'octave<128' is not redundant opencv-5.0.0/modules/features/src/sift.dispatch.cpp:172:21: note: Assuming condition 'octave<128' is false opencv-5.0.0/modules/features/src/sift.dispatch.cpp:172:27: note: Assignment 'octave=octave<128?octave:(-128|octave)', assigned value is -128 opencv-5.0.0/modules/features/src/sift.dispatch.cpp:173:57: note: Shift Explanation: `octave = kpt.octave & 255` lies in 0..255. When it is 128 or more, `-128 | octave` gives a value in -128..-1. For octave == 128 the result is exactly -128, so line 173 evaluates `1 << 128`, which is undefined behaviour. Any -octave of 32 or more is also UB. `kpt.octave` comes from caller-supplied KeyPoint data, so this path is reachable from the function's own logic. Cppcheck's chain (condition false, assigned value -128, shift by 128) is sound, even though real SIFT octaves are usually small. The new warning is a valid input-dependent true positive that the PR's improved ternary value tracking now exposes. ---- 47 / 50 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/p/pcl/pcl_1.15.1+dfsg.orig.tar.xz Result: your pcl-pcl-1.15.1/io/src/obj_io.cpp:665:34: warning: Either the condition 'n<0' is redundant, otherwise there is negative array index -1. [negativeContainerIndex] pcl-pcl-1.15.1/io/src/obj_io.cpp:663:20: note: Assuming that condition 'n<0' is not redundant pcl-pcl-1.15.1/io/src/obj_io.cpp:663:20: note: Assuming condition 'n<0' is false pcl-pcl-1.15.1/io/src/obj_io.cpp:663:25: note: Assignment 'n=(n<0)?normal_idx+n:n-1', assigned value is -1 pcl-pcl-1.15.1/io/src/obj_io.cpp:665:34: note: Negative array index Explanation: The face parser reads `n` from the file with `std::stoi`. The false branch of `n<0` covers every `n >= 0`, including `n == 0`. In that case `n - 1` is -1 and `normals[-1]` is read out of bounds. OBJ indices are 1-based, so 0 is invalid, but the code never checks for it. A malformed file such as `f 1//0` would trigger the bad access. The reasoning chain is consistent: the condition is false, `n` is 0, the assigned value is -1. The PR intentionally lets values implied by a condition flow into the ternary branches, and that is what produces this warning. It looks like a real (if input-dependent) bug. Confidence is low because the -1 comes only from the boundary value of the condition, and the other new warning in this package (hog.cpp) looks like a false positive from the same change. ---- 48 / 50 ---- Verdict: REGRESSION (high confidence) Package: https://ftp.debian.org/debian/pool/main/p/pcl/pcl_1.15.1+dfsg.orig.tar.xz Result: your pcl-pcl-1.15.1/people/src/hog.cpp:513:20: warning: Invalid std::acos() argument nr 1. The value is -1.01 but the valid values are '-1.0:1.0'. [invalidFunctionArg] pcl-pcl-1.15.1/people/src/hog.cpp:509:13: note: Assignment 'i=0', assigned value is 0 pcl-pcl-1.15.1/people/src/hog.cpp:511:20: note: Assignment 't=i*ni-1.01f', assigned value is -1.01 pcl-pcl-1.15.1/people/src/hog.cpp:512:23: note: Assuming condition 't>1' is false pcl-pcl-1.15.1/people/src/hog.cpp:512:10: note: Assuming condition 't<-1' is false pcl-pcl-1.15.1/people/src/hog.cpp:512:14: note: Assignment 't=t<-1?-1:(t>1?1:t)', assigned value is -1.01 pcl-pcl-1.15.1/people/src/hog.cpp:513:20: note: Invalid argument Explanation: When i=0, t=-1.01. Line 512 then clamps it: 't<-1' is true, so t becomes -1. The note 'Assuming condition t<-1 is false' contradicts the known value -1.01, and the clamp guarantees the argument to acos is within [-1,1]. The PR removed the check that kept known values from passing through '?' branches as possible values. Because of that, the value -1.01 now propagates through the false branch even though the condition is known true. This new invalidFunctionArg warning is a false positive. ---- 49 / 50 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/x/xfce4-panel/xfce4-panel_4.20.8.orig.tar.bz2 Result: your xfce4-panel-4.20.8/plugins/pager/pager-buttons.c:385:31: warning: Either the condition '1>(n_viewports)' is redundant or there is division by zero at line 385. [zerodivcond] xfce4-panel-4.20.8/plugins/pager/pager-buttons.c:384:18: note: Assuming that condition '1>(n_viewports)' is not redundant xfce4-panel-4.20.8/plugins/pager/pager-buttons.c:384:18: note: Assuming condition '1>(n_viewports)' is true xfce4-panel-4.20.8/plugins/pager/pager-buttons.c:384:18: note: Assignment 'rows=(1>(n_viewports))?(n_viewports):((1<(pager->rows))?(pager->rows):1)', assigned value is 0 xfce4-panel-4.20.8/plugins/pager/pager-buttons.c:385:31: note: Division by zero Explanation: The new warning is triggered by the GLib CLAMP macro, which expands to `(1 > n_viewports) ? n_viewports : ...`. That condition is generic macro code, not a check the programmer wrote because they expected `n_viewports` could be below 1. The PR now carries the ternary's possible values into `rows`. In theory `n_viewports` is 0 if `rect->width` or `rect->height` is 0: the modulo checks pass and `rows` becomes 0, so `cols = n_workspaces / rows` would divide by zero. In practice a virtual workspace geometry is unlikely to be empty. The companion warning at line 404 is clearly a false positive, since `n_workspaces >= 1` after the NULL check. Whether this one is a useful finding or macro-induced noise cannot be decided from the code shown. ---- 50 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/x/xfce4-panel/xfce4-panel_4.20.8.orig.tar.bz2 Result: your xfce4-panel-4.20.8/plugins/pager/pager-buttons.c:404:27: warning: Either the condition '1>(n_workspaces)' is redundant or there is division by zero at line 404. [zerodivcond] xfce4-panel-4.20.8/plugins/pager/pager-buttons.c:403:14: note: Assuming that condition '1>(n_workspaces)' is not redundant xfce4-panel-4.20.8/plugins/pager/pager-buttons.c:403:14: note: Assuming condition '1>(n_workspaces)' is true xfce4-panel-4.20.8/plugins/pager/pager-buttons.c:403:14: note: Assignment 'rows=(1>(n_workspaces))?(n_workspaces):((1<(pager->rows))?(pager->rows):1)', assigned value is 0 xfce4-panel-4.20.8/plugins/pager/pager-buttons.c:404:27: note: Division by zero Explanation: The condition `1>(n_workspaces)` is not one the programmer wrote. It comes from GLib's generic `CLAMP(1, pager->rows, n_workspaces)` macro expansion. So it does not show that the author expects `n_workspaces` to be below 1. The zerodivcond check assumes that if the condition can be true, the value 0 can reach the division. That reasoning is flawed here. `n_workspaces` comes from `g_list_length` of the workspace list, which in practice always has at least one entry. The new warning comes from the PR's change in how conditional values flow out of `?:` expressions. It is most likely a false positive driven by the macro.