{ "tokens": { "input": 197060, "cache_read": 59942, "cache_write": 13158, "output": 41252 }, "reviews": [ { "key": [ "https://ftp.debian.org/debian/pool/main/f/fbb/fbb_7.013.orig.tar.gz", "main fbb-7.0.13/src/driver.c:347:33: style: Argument 'port,0' to function snd is always 0. It does not matter what value 'port' has. [knownArgument]" ], "verdict": { "verdict": "improvement", "confidence": "high", "explanation": "Line 347 calls a function pointer: `(drv_fct[p].snd)(port, 0, ...)`. The commas there separate function arguments; there is no comma operator. Cppcheck wrongly read `port,0` as a comma expression and reported it as always 0. The PR now also treats `(` whose astOperand1 is `.` or `[` as a function call, so the false positive is removed." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "main ../../src/builtin/snarf.m4:1035:1: error: Unmatched '{'. Configuration: '__GNUC__=1'. [syntaxError]" ], "verdict": { "verdict": "unclear", "confidence": "medium", "explanation": "The removed 'Unmatched {' syntaxError points at an m4 template, through #line mapping in generated C code. The PR only changes a ValueFlow condition for comma operators in function-call parents. Unmatched-brace errors come from the tokenizer and preprocessor, which this change should not affect. The rest of the diff also looks like noise: burst.bi results disappear and unrelated debug.bi results appear. That suggests nondeterministic or timeout-related differences in which files were analyzed, not an effect of this PR. The error may well have been a false positive, but there is no clear causal link." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "main burst.bi:267:32: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable CLEANUP_THROW [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "unclear", "confidence": "medium", "explanation": "The removed line is a debug bailout: CLEANUP_THROW is a macro argument Cppcheck cannot resolve. The PR only changes how a comma inside a call through a function-pointer expression (`(p->f)(...)`, `s.a[0](...)`) is handled in valueflow. That cannot make CLEANUP_THROW a complete variable. The same run also dropped every burst.bi message and the snarf.m4 syntaxError, while adding many debug.bi messages. This looks like a change in which files or configurations were analyzed (nondeterminism, ordering, or a timeout), not a change in how this code is understood. There is not enough evidence to call it an improvement or a regression." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "main burst.bi:28:77: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable SYM_PRECIOUS [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "unclear", "confidence": "medium", "explanation": "Line 28 is a macro-style declaration `MF_VAR(burst_eb_min_length, NUMBER, SYM_PRECIOUS);`, and SYM_PRECIOUS is still an unknown identifier. The PR only changes how a comma inside a call whose callee is `[`, `*` or `.` is treated in value flow. That has nothing to do with incomplete-variable bailouts, so this message did not go away because Cppcheck now understands the code better. All burst.bi messages and the snarf.m4 syntax error disappear together, while unrelated debug.bi messages appear. That pattern points to a difference in which file or configuration was analyzed or reported, not to an effect of the PR. Its value for users cannot be judged." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "main burst.bi:399:32: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable CLEANUP_ALWAYS [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "This is a debug bailout about the incomplete variable CLEANUP_ALWAYS, an unknown macro argument. The PR only changes how ValueFlow treats a comma inside a call through a callee expression like `(p->f)(...)` or `s.a[0](...)`. That has nothing to do with incomplete-variable bailouts. Every burst.bi line disappears together while many debug.bi lines appear, which points to a change in which files or configurations got analyzed (run noise), not to better understanding of this code. The message still applies to this code, so its removal does not matter to users." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "main burst.bi:512:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_burst [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "unclear", "confidence": "medium", "explanation": "The removed line is a valueFlowBailoutIncompleteVar debug message about BUILTIN_IDX_burst. That macro-generated identifier is still undefined, so Cppcheck does not understand this code any better. The PR only changes how a comma inside a call through a function pointer expression (`(p->f)(...)`, `s.a[0](...)`) is treated in valueflow, which has nothing to do with incomplete variables. The package diff shows all burst.bi messages (and a snarf.m4 syntaxError) disappearing while the same kinds of messages appear for debug.bi. That pattern suggests a change in which file or configuration got analyzed or reported, not a semantic effect of the PR. It cannot be classified reliably." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "main burst.bi:512:68: error: Uninitialized variable: flags [legacyUninitvar]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "The warning is on an `MF_DEFUN(...)` line in an m4-templated `.bi` file. Cppcheck cannot see what the macro expands to, so the 'uninitialized flags' report is very likely a false positive on a function parameter. However, the whole set of burst.bi warnings disappeared (along with a snarf.m4 syntax error), and an equivalent set appeared for debug.bi, including the same kind of legacyUninitvar on `seconds`. That pattern suggests a different file or configuration was analysed, not an effect of the PR's comma/function-call valueflow change. So the removal cannot be clearly credited to the PR." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "main burst.bi:512:82: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "The warning points at the `MF_DEFUN(...)` line of an m4-generated .bi file. The `|` expression comes from code expanded through `#line` mappings and is not visible in the source shown, so we cannot tell whether it is a true or false positive. All the other burst.bi diagnostics also disappeared, while many debug.bi diagnostics and a snarf.m4 syntax error changed. That looks like a shift in which generated code or configuration got analyzed, not a direct effect of the PR's change to comma/function-call handling in setTokenValue. There is not enough information to judge the removal." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "main burst.bi:512:82: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "Line 512 is an unexpanded m4 `MF_DEFUN(...)` macro in a `.bi` template. Cppcheck cannot meaningfully analyse it, so the duplicateExpression warning there is noise rather than a real finding. The whole burst.bi group of messages disappears, including its bailout, uninitvar and badBitmaskCheck lines. At the same time, the identical pattern of messages appears for debug.bi at its `MF_DEFUN` lines. That points to a change in which file or configuration was analysed (possibly related to the snarf.m4 syntax error changing), not to the PR's comma-in-call handling. The PR only changes how a comma inside a call through `[`, `.` or `*` is treated. Neither file's warning is clearly affected by it, so the net effect for users is negligible." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:122:9: style: Variable 'p' can be declared as pointer to const [constVariablePointer]" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "In format_frame, `char *p = strchr(fmt, '%');` is only read: it is tested for null and used in `p - fmt`. Nothing is ever written through it. Since fmt is `char const *`, declaring p as `const char *` is correct and safer, so this constVariablePointer warning is a true positive. The whole debug.bi file shows up only in 'your' output, which suggests main never analysed this code (the snarf.m4 syntax error and file differences point that way). Either way, the new warning is valid." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:161:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "medium", "explanation": "This is a valueFlowBailoutIncompleteVar debug message. It fires because the macro-generated identifier BUILTIN_IDX_debug is unknown to Cppcheck, so Cppcheck still does not understand this code. The PR only changes how a comma inside a call through `(expr)`, `a[i](...)` or `s.f(...)` is treated in setTokenValue. That has nothing to do with incomplete-variable bailouts. The diff shows a whole block of burst.bi messages disappearing and a matching block of debug.bi messages appearing, along with a snarf.m4 syntax error in main. This points to a difference in which preprocessed file or configuration got analyzed, not to the PR changing how Cppcheck understands this function. A debug message like this has no value to users either way." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:161:92: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "Column 92 is past the end of the `MF_DEFUN(stack_trace_format, ...)` line. So the warning points into m4/macro-generated code (likely a flags expression such as `0|0`) that is not shown here. The same `badBitmaskCheck` and `duplicateExpression` pair disappeared from burst.bi at the same time, and a main-only syntaxError in snarf.m4 also vanished. A ValueFlow comma/function-call change should not affect a tokenizer syntax error. This looks like a change in which generated file got analyzed, not a direct effect of the PR. Without the expanded code, I cannot tell whether the warning is a real finding or noise." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:161:92: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "Line 161 is an `MF_DEFUN(...)` macro line from an m4-generated .bi file, and column 92 is past the visible text. The `0|0`-style duplicate operand must therefore come from macro expansion we cannot see, which is likely harmless code generated by the macro rather than a real bug. The same warnings (badBitmaskCheck, duplicateExpression, BUILTIN_IDX bailout) disappear from burst.bi and appear in debug.bi. That looks like a shift in which file or configuration got analyzed. It does not look like an effect of the PR's change to comma handling in function-call valueflow, which this code does not exercise. There is not enough information to tie this result to the PR." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:184:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "unclear", "confidence": "medium", "explanation": "This bailout is one of a whole block of new debug.bi warnings. At the same time, main reports an \"Unmatched '{'\" syntaxError (snarf.m4) plus a burst.bi block that `your` lacks. That pattern points to a different set of files or configurations being analysed between the two runs, not to this PR. The PR only changes how a known value is passed through a comma inside a function call such as `(p->f)(x, 10)` or `s.a[0](x, 10)`. It cannot change tokenizer syntax errors or whether `BUILTIN_IDX_debug` (an identifier from the MF_DEFUN macro) is seen as an incomplete variable. There is no evidence that the PR changed how Cppcheck understands this code." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:184:86: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "Line 184 is a `MF_DEFUN(...)` macro invocation from an m4-generated .bi file. Column 86 is past the end of the source line, so the warning points into the macro expansion. That expansion most likely ORs flag constants that happen to be 0, a common, intentional pattern in macro-generated code. The identical warning set (badBitmaskCheck, duplicateExpression, legacyUninitvar, bailouts) disappears from burst.bi and appears in debug.bi. That looks like a change in which file or configuration got analyzed (there is also a snarf.m4 syntax error), not like an effect of the PR. The PR only changes how ValueFlow treats commas inside calls through function-pointer expressions (`[`, `*`, `.`), which does not plausibly create a `0 | 0` bitmask warning here. The warning is probably noise in macro code, but the link to the PR cannot be established." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:184:86: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "Line 184 is an `MF_DEFUN(...)` macro invocation in an m4-generated .bi file. The `0|0`-style duplicate operand is produced by the macro expansion (likely a flags argument built from zero-valued options), not written by the user. The warning is at best style noise from macro-generated code. Main reports exactly the same pattern of warnings for burst.bi; this run reports it for debug.bi instead, and the snarf.m4 syntaxError disappears. That points to a difference in which file or configuration was analyzed, not to the PR. The PR only changes how comma-separated values are propagated inside calls like `(p->f)(x,10)` and `s.a[0](x,10)`, which does not plausibly cause a new duplicateExpression here. There is not enough information to attribute this change to the PR or to judge it." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:197:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "medium", "explanation": "This is a valueFlowBailoutIncompleteVar debug message. It fires because the MF_DEFUN macro expansion uses BUILTIN_IDX_debug, which is generated by m4 and never defined in the analyzed source. The PR only changes how ValueFlow treats a comma whose parent '(' follows a '[', '*' or '.' expression, so it cannot create an unknown identifier. The diff for this package also swaps whole files: all burst.bi results and a snarf.m4 syntaxError disappear, and debug.bi results appear wholesale. That points to a different set of analyzed files between the runs, not a change in Cppcheck's understanding of this code. The new debug line is noise for users." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:197:64: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "The warning points at an m4 `MF_DEFUN` line in debug.bi, so it comes from m4-generated C code that is not shown. It most likely flags a generated `x | 0` flags expression. The diff swaps a whole set of identical warnings: the same kinds of warnings and bailouts disappear from burst.bi, a snarf.m4 syntaxError disappears, and they reappear for debug.bi. That looks like a different file or configuration being analysed, not an effect of the comma/function-call valueflow change. Without the generated code it is not possible to tell whether the PR caused this or whether it is right or wrong." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:197:64: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "Line 197 is an m4 `MF_DEFUN(_reg, NUMBER, NUMBER what)` invocation in generated code. The warning comes from a macro or m4 expansion that produces something like `0 | 0` in a flags argument. The same warning set was reported for burst.bi in main, and here it moves to debug.bi together with the snarf.m4 syntaxError. That points to different files or configurations being analysed, not to the PR's change to comma/function-call value propagation, which has no evident link to this `|` expression. The source shown does not include the expanded code, so whether this warning is a true or false positive cannot be judged." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:204:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "medium", "explanation": "This is an m4-templated .bi file, and BUILTIN_IDX_debug comes from an unexpanded MF_DEFUN macro, so the 'incomplete variable' bailout is expected for this input. It does not reflect worse understanding caused by the PR. The PR only changes when a comma's value is propagated through a call such as (p->f)(...) or s.a[0](...). That cannot introduce a missing-declaration bailout. The whole diff swaps a set of burst.bi messages for analogous debug.bi messages, which points to a difference in which file/configuration got analyzed, not a semantic change. The message has no practical impact on users." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:204:91: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "debug.bi is an m4 template, not real C. The `MF_DEFUN(...)` line only becomes C after macro expansion. Column 91 on a roughly 45-character line shows the warning points into expanded macro text, probably a generated flags expression like `X | 0`. Neither the expansion nor the `|` operands are visible. The pattern also looks like output shuffling rather than a semantic change: the same kinds of warnings (badBitmaskCheck, duplicateExpression, legacyUninitvar, BUILTIN_IDX bailouts) disappear for burst.bi and appear for debug.bi. The PR only changes how comma-operator values are propagated in call arguments, which does not obviously explain this. Whether the redundant `| 0` is a real finding or macro-generated noise cannot be decided from what is shown." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:204:91: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "Line 204 is an m4 `MF_DEFUN(...)` construct in a `.bi` template, not plain C. The warning at column 91 points into whatever the macro expands to, presumably a flags expression like `X | X` or `0 | 0`, and that expansion is not shown, so its correctness cannot be judged. The PR only changes when a comma inside a call such as `(p->f)(x,10)` or `s.a[0](x,10)` is treated as a function-call comma. Nothing here obviously relates to that. The diff pattern also looks like a wholesale shift rather than a targeted change: every burst.bi finding and a snarf.m4 syntaxError disappear, and an identical set of finding types appears for debug.bi. The source of the change and whether this warning is a true or false positive cannot be determined from the information given." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:212:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "Line 212 is an m4-templated `MF_DEFUN(_stack_free, NUMBER)` in debug.bi. The macro is not expanded for Cppcheck, so `BUILTIN_IDX_debug` is genuinely an unknown identifier and the incomplete-variable bailout is expected. The PR only changes how comma values propagate when the call target is a function-pointer expression (`[`, `*`, `.`). That cannot create or remove an incomplete-variable bailout. The diff instead shows a whole-file swap: burst.bi messages disappeared and debug.bi messages appeared. This most likely comes from which file got analyzed (or a run difference), not from a change in code understanding. The debug message has no user-facing value either way." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:212:78: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "unclear", "confidence": "medium", "explanation": "Line 212 is an m4-templated `MF_DEFUN(_stack_free, NUMBER)` declaration. The `0 | 0` expression Cppcheck flags comes from macro or m4 expansion of the builtin flags. That makes it generated-code noise rather than a real bitmask mistake. The same kind of warning disappeared for burst.bi and appeared for debug.bi, and the snarf.m4 syntax error also vanished. This looks like a change in which configuration or file content got analysed, not a direct effect of the PR's comma/function-call ValueFlow change. The source does not show enough to tie this warning to the PR." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:212:78: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "The warning points at a `MF_DEFUN(...)` line in an m4-processed `.bi` file, so the `|` it complains about comes from macro expansion. A wrong expansion could easily produce something like `0|0`, but the expansion is not shown. The PR only changes how known values pass through comma operators inside calls through function-pointer expressions (`(p->f)(...)`, `s.a[0](...)`). That should not affect duplicateExpression on this line. The same warnings disappeared from burst.bi and appeared in debug.bi, and the snarf.m4 syntax error vanished. That pattern suggests a change in which files or configurations were analyzed, not a direct effect of the PR. Without the macro expansion, I can't tell whether the warning is valid." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:219:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "debug.bi is m4-templated mailfromd source. `MF_DEFUN` and `BUILTIN_IDX_debug` are not defined, so Cppcheck cannot resolve `BUILTIN_IDX_debug` and emits a valueFlowBailoutIncompleteVar debug message. That bailout has nothing to do with the PR, which only changes how commas inside calls through function-pointer expressions (`(p->f)(...)`, `s.a[0](...)`) get values. The whole package diff looks like a different set of files being reported: all burst.bi and snarf.m4 messages vanished and a full set of debug.bi messages appeared. This is probably a run or processing artifact rather than a change in how Cppcheck understands this code. The message does not matter to users either way." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:219:82: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "Cppcheck reports this at the MF_DEFUN line of an m4-generated builtin file (debug.bi). The '|' with a zero operand comes from macro or generator expansion (likely a flags argument such as `0|0`), not from code the author wrote. Main reported the identical badBitmaskCheck/duplicateExpression pattern for burst.bi. The whole diff looks like a different file or configuration being analyzed: burst.bi's results and the snarf.m4 syntaxError disappeared, and debug.bi's appeared. The PR only changes how a comma inside a call through `(p->f)(...)` or `s.a[0](...)` is treated, which has no visible link to this warning. The warning is technically correct but low-value noise in generated code, and the source shown does not explain why it appeared." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:219:82: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "debug.bi is an m4 template, not real C. Line 219 is only about 46 characters long, so column 82 must point into an expanded MF_DEFUN macro. The warning is probably about a constant flags expression like `0 | 0` produced by the macro, which is harmless generated code rather than a real bug. The same warnings for burst.bi disappeared in main at the same time as all of debug.bi appeared. That points to a change in which file was analysed (e.g. snarf.m4's syntax error going away), not to the PR's change to comma handling in function calls. The source shown does not let us tell whether the PR caused this or whether it is a true or false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:21:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "medium", "explanation": "The PR only changes how a comma operand's value is propagated when the comma sits inside a call through `[`, `*` or `.` (e.g. `s.a[0](x, 10)`). This message is an incomplete-variable bailout caused by the unknown macro identifier `BUILTIN_IDX_debug` from `MF_DEFUN`, which has nothing to do with that logic. The diff as a whole also changed which file was analysed: all `burst.bi` results and the `snarf.m4` syntax error disappeared, and the same kinds of messages appeared for `debug.bi`. So this line comes from analysing a different file, not from the PR changing Cppcheck's understanding of the code. It does not matter to users either way." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:21:57: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable dtype_number [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "This bailout is about `dtype_number`, an identifier produced by the unexpanded `MF_DEFUN` macro, which Cppcheck cannot resolve. That has nothing to do with the PR's change to comma/function-call handling in `setTokenValue`. The rest of the diff suggests the same thing. All of the `burst.bi` output and the `snarf.m4` tokenizer syntaxError disappear, while the whole of `debug.bi` appears with the same kinds of messages. That pattern points to a different file or configuration being analyzed in this run, not to the PR making Cppcheck understand this code worse. The incomplete-variable bailout would appear whenever this function is analyzed, so it tells users nothing new." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:21:78: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "The warning is reported at the `MF_DEFUN(debug_level, NUMBER, OPTIONAL, STRING modname)` line, so it comes from a macro expansion whose definition is not shown. It probably expands to a flags expression such as `0|0`; if so, the redundancy is generated code and the warning is noise. However, main already reported the same warnings (duplicateExpression, badBitmaskCheck, legacyUninitvar) for the same macro pattern in burst.bi:512. The PR only stops values from propagating through commas when the call target is `[`, `*` or `.` (calls through function-pointer members or array elements). That has no visible link to this code, so the burst.bi to debug.bi shift looks like a change in which files were analyzed (note also the snarf.m4 syntax error difference) rather than an effect of the PR. Without the macro expansion it cannot be decided whether this is a true positive or a false positive caused by the change." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:225:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "medium", "explanation": "The new line is a valueFlowBailoutIncompleteVar debug message. It appears because `BUILTIN_IDX_debug` is an m4/macro-generated identifier that Cppcheck cannot resolve inside the `MF_DEFUN` expansion. The PR only changes how a comma inside a function-call parent is treated during value propagation. It does not affect which variables are incomplete. The overall diff swaps burst.bi results for debug.bi results, and main's snarf.m4 syntaxError also disappears. That pattern points to a change in which file or configuration was analyzed, not to anything the PR does. The debug message is not caused by the PR and does not matter to users." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:225:48: error: Uninitialized variable: seconds [legacyUninitvar]" ], "verdict": { "verdict": "regression", "confidence": "low", "explanation": "`seconds` is an OPTIONAL builtin argument. It is only read through `MF_OPTVAL(seconds)`, which in mailfromd's generated code is guarded by the argument count, so it is very likely never read uninitialized. Column 48 is inside the expansion of the `MF_DEFUN` macro on that one line, which points to cppcheck misreading generated code rather than finding a real bug. A similar `legacyUninitvar` in burst.bi disappeared at the same time. This suggests a shift in what code is analyzed rather than better understanding. The new warning is most likely a false positive, but the exact macro expansion is not shown." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:225:67: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "unclear", "confidence": "medium", "explanation": "Line 225 is an m4 `MF_DEFUN(_wd, VOID, OPTIONAL, NUMBER seconds)` template, and the warning points into code generated from it via #line mapping. The `0 | 0` the warning refers to is not visible, so its correctness cannot be judged. The same warning pattern was reported in main for burst.bi and now appears for debug.bi. The main-only syntaxError in snarf.m4 also disappears. This suggests a different set of generated code was analyzed, not a direct effect of the PR. The PR only stops ValueFlow from passing comma values into calls through `[`, `*` or `.` callees, which would remove values rather than add this warning. There is not enough information to attribute or evaluate it." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:225:67: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "medium", "explanation": "debug.bi is an m4 template, not plain C. Line 225 is the macro call `MF_DEFUN(_wd, VOID, OPTIONAL, NUMBER seconds)`, and column 67 lies past the end of that line, so the warning refers to code produced by macro expansion. That expansion is not shown. The same set of warnings (badBitmaskCheck, duplicateExpression, legacyUninitvar, incomplete-variable bailouts) disappears from burst.bi and appears for every MF_DEFUN in debug.bi. A syntax error in snarf.m4 also disappears. This looks like a change in which files or configurations were analysed, not something caused by the PR. The PR only changes how ValueFlow treats commas inside calls through `(...)`, `[...]`, `*` or `.` expressions, and nothing here obviously involves that. Without the expanded code, it cannot be said whether the `|` duplicate is real or whether this difference comes from the PR at all." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:34:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "The new line is a debug bailout: `MF_DEFUN` expands to code using `BUILTIN_IDX_debug`, a generated identifier whose definition is not available, so the variable is incomplete. The PR only changes how ValueFlow treats commas inside calls through `(...)`, `[...]`, `*` and `.` expressions. That cannot change incomplete-variable detection. The whole diff swaps all burst.bi messages for the equivalent debug.bi messages, and a snarf.m4 syntax error also disappears. This looks like a change in which included .bi file got analyzed, not a change in how Cppcheck understands this code. The message is accurate either way and does not matter to users." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:34:76: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "unclear", "confidence": "medium", "explanation": "Line 34 is an unexpanded `MF_DEFUN(...)` macro line in an m4-preprocessed .bi file. It contains no '|' operator, and column 76 lies past the visible text, so the warning comes from macro-generated code, most likely flag bits that both expand to 0. The PR only changes how ValueFlow decides whether a comma belongs to a function call. It is hard to see how that alone would make all of debug.bi newly analyzed while the matching burst.bi warnings and a snarf.m4 syntaxError disappear. The diff looks like a shift in which file or configuration gets analyzed, not a real change in understanding. Main reported the identical badBitmaskCheck pattern for burst.bi. The source shown is not enough to tell whether this is a true or false positive, or how it relates to the PR." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:34:76: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "regression", "confidence": "low", "explanation": "Line 34 is an unexpanded MF_DEFUN(...) wrapper, and column 76 lies past the end of the visible text, so the warning points into macro-generated code. The paired badBitmaskCheck says one operand of '|' is zero. That suggests two flag macros that both expand to 0 being OR'ed, which is a normal pattern for building flags. Reporting 'same expression on both sides' for it is noise the user cannot act on. This new duplicateExpression comes with many other new warnings and bailouts on the same macro lines. The PR only changes how comma values pass through call-like parents, so this looks like a side effect producing a false positive rather than a real finding." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:68:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "This bailout fires because `BUILTIN_IDX_debug` is a generated identifier that is not defined in the analyzed sources. The PR does not change how that variable is resolved. The message appears only because debug.bi is now analyzed at all. In main, a tokenizer-level `syntaxError` (reported via snarf.m4) stopped that analysis, and burst.bi results also disappeared. A ValueFlow change like this PR cannot plausibly cause that, so the difference likely comes from the run environment or file set, not from Cppcheck understanding the code worse. The message does not matter to users." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:68:71: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "Line 68 is the macro-heavy `MF_DEFUN(debug, VOID, STRING spec)` line in an m4-generated .bi file. Column 71 lies past the visible text, so the `x | 0` is in the macro expansion, which is not shown. The same warning set disappears for burst.bi and appears for debug.bi, and main's snarf.m4 syntax error goes away. That points to a different file or configuration being analysed, not to the PR's valueflow change. The PR only stops setting comma values in more call-like contexts, which would tend to remove known-zero values rather than add them. Without the expanded macro, there is no way to tell whether a redundant `| 0` really exists there or whether the warning is a false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:68:71: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "Line 68 is an m4 `MF_DEFUN` stub; column 71 lies past the end of that source line. So the warning points into generated or expanded code mapped back via #line, likely a builtin registration with a flags expression such as `0 | 0`. The same badBitmaskCheck/duplicateExpression pattern was reported for burst.bi on main and disappeared, while debug.bi gained it. That looks like a shift in which generated translation unit got analyzed (main also had an 'Unmatched {' syntax error in snarf.m4), not a direct effect of the comma/function-call valueflow change. The source shown does not let me tell whether the duplicated operands are real or a macro artifact." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:81:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "The new line is a valueFlowBailoutIncompleteVar debug message. It fires because `BUILTIN_IDX_debug`, produced by the unexpanded `MF_DEFUN` macro, has no visible declaration. That is a property of the code, not of the PR. The PR only changes how a comma inside a function call is treated in ValueFlow (`(p->f)(x, 10)` and `s.a[0](x, 10)`). It does not affect incomplete-variable detection. The overall diff swaps a whole block of burst.bi results for debug.bi results and drops a tokenizer syntaxError in snarf.m4. That pattern points to different code being analyzed between the runs (configuration or file-order differences), not to this PR. The debug message does not show Cppcheck understanding the code worse, and it does not matter to users." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:81:87: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "Line 81 is a short MF_DEFUN line, yet the warning is at column 87. That means it points into code generated from the m4/#line-mapped .bi source, probably a builtin registration flags expression like `0 | 0`. Main reports the identical pattern (badBitmaskCheck, duplicateExpression and the incomplete-variable bailout) for burst.bi. In this run burst.bi's warnings vanished and debug.bi's appeared, which looks like a change in which generated file got analysed (main also had a snarf.m4 syntax error). The PR only changes how a value flows through a comma in a call through a function pointer, `[`, `*` or `.`; it should not create or remove a constant `0 | 0` expression. The warning is the same kind of stylistic noise on generated code that main already reports elsewhere, so it does not reflect a real gain or loss." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:81:87: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "Line 81 is an m4 `MF_DEFUN(...)` line in a `.bi` source that is expanded into generated C. Column 87 is past the end of the visible text, so the flagged `x | x` comes from macro-generated code that is not shown. The same set of warnings disappeared from burst.bi in main, along with an unrelated syntaxError in snarf.m4, and appeared in debug.bi in your run. That looks like a change in which generated file got analyzed, not something caused by the PR's comma/function-call change in setTokenValue. Without the expanded code, it cannot be told whether the duplicate operand is real or a false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:87:101: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "Line 87 is an unexpanded m4 `MF_DEFUN` in a `.bi` source. Column 101 lies past the end of the visible line, so the warning comes from the generated C code mapped back via `#line`. That generated code ORs in a flags value that is 0, so `badBitmaskCheck` is technically true but is noise from generated code. The same warning pattern appears in main for `burst.bi` and disappears there, while it now appears for `debug.bi`. Main also reports a syntax error in `snarf.m4`. This suggests the change in which file or section gets reported comes from analysis differences, not from the PR's logic. The PR only treats `(p->f)(...)` and `s.a[0](...)` as function calls in comma-value propagation. The warning is not clearly a new false positive or a meaningful true positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:87:101: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "medium", "explanation": "Line 87 is an `MF_DEFUN(...)` line in an m4-preprocessed `.bi` file. Column 101 lies inside the macro expansion, which presumably produces something like `0 | 0` for the builtin flags. That is intentional generated code, not a real duplicated expression. Main reported the same warning groups for burst.bi (`badBitmaskCheck`, `duplicateExpression`, `legacyUninitvar`, `valueFlowBailoutIncompleteVar`), and main's snarf.m4 syntax error is gone in your run. So the diff looks like warnings moving between files or a different preprocessing outcome. It does not look like a semantic effect of the PR's change to comma/function-call detection in `setTokenValue`. Without the expanded source it is not possible to tie this warning to the PR, so the effect is unclear." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:87:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "medium", "explanation": "The new line is a valueFlowBailoutIncompleteVar debug message. It fires because the macro-generated identifier BUILTIN_IDX_debug (from MF_DEFUN) is undeclared in the checked code. Cppcheck either sees that identifier or it does not; the PR only changes how values pass through commas in function-call-like parents, so it should not affect this. The whole diff looks like a change in which files or configurations were analyzed, not a change in understanding: main reports burst.bi lines and a snarf.m4 syntax error, while 'your' reports the same kinds of messages for debug.bi. This debug line therefore carries no meaningful information for users." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:93:27: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable BUILTIN_IDX_debug [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "The new line is a valueFlowBailoutIncompleteVar debug message about BUILTIN_IDX_debug, which comes from the unexpanded MF_DEFUN macro in debug.bi. The PR only changes how a comma inside a call through `p->f`, `a[0]` or `(...)` gets a value, which has nothing to do with incomplete-variable bailouts. All burst.bi/snarf.m4 output disappeared and all debug.bi output appeared, including the same kinds of messages. That pattern suggests a different preprocessed file was analyzed, not a change in how Cppcheck understands this code. A debug message like this does not matter to users either way." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:93:83: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "Line 93 is a `MF_DEFUN(stack_trace, VOID)` macro invocation. Column 83 is past the end of the source text, so the warning points into the macro expansion, which is not shown. That expansion apparently builds a flags expression such as `X | 0`. The same pair of badBitmaskCheck and duplicateExpression warnings vanished from burst.bi and appeared in many debug.bi lines. This looks like a shift in which file or configuration was fully analyzed (the snarf.m4 syntax error also disappeared), not an effect of the PR. The PR only changes when a value is set on a comma in function-pointer calls through `[`, `*` or `.`. Without the macro expansion it is impossible to tell whether the warning is a real redundancy or macro-generated noise, or how the PR caused it." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mailfromd/mailfromd_9.1.orig.tar.xz", "your debug.bi:93:83: style: Same expression on both sides of '|'. [duplicateExpression]" ], "verdict": { "verdict": "unclear", "confidence": "medium", "explanation": "Line 93 is an m4 macro invocation, `MF_DEFUN(stack_trace, VOID)`, in a .bi file that is preprocessed into C. Cppcheck cannot see the expanded code. Together with the paired badBitmaskCheck, the warning suggests the expansion produces something like `0|0` in generated flags. That would be harmless macro noise, not a real bug. The PR only changes how values propagate through comma operators inside function-call parentheses, and it is not obviously related to this warning. Main reported the same kinds of warnings (badBitmaskCheck/duplicateExpression/bailouts) for burst.bi, while your reports them for debug.bi. This looks like a change in which generated file or location gets reported, not a change in analysis of this code. There is not enough information to call it a true or false positive caused by the PR." } } ], "started": "2026-10-13 20:26:26 UTC", "runner": "pc" }