On Thu, 12 Mar 2026 16:28:23 +0000 Bruce Richardson <[email protected]> wrote:
> Yes, it's disabled for the drivers, but if we enable it for raw/ifpga > driver, how come this macro doesn't give the warning when it uses the exact > same structure as the original code? Short answer, clang treats macros as special case for comma operator. As always AI has longer answer... Great question — this is a well-known Clang behavior that trips people up. Clang's `-Wcomma` warning fires when it sees a comma operator where the left-hand side result is discarded, since that's often a bug (someone meant `&&` or `;` instead of `,`). The expression `(tmp = TAILQ_NEXT(dfl, node), 1)` is a textbook trigger: the assignment result is discarded and only the `1` is used. However, Clang deliberately suppresses most warnings — including `-Wcomma` — for code that originates from macro expansions. The rationale is that macro-expanded code is an established idiom the user didn't write directly at that call site, so warning on it would generate noise that the caller can't reasonably fix. The warning logic checks whether the expression's source location traces back to a macro expansion and, if so, skips the diagnostic. So the two cases are semantically identical after preprocessing, but Clang's diagnostic engine distinguishes them by source location: **Inline version** — the comma operator appears directly in your source code → Clang assumes you wrote it intentionally and warns you in case you didn't. **Macro version** — the comma operator is inside `TAILQ_FOREACH_SAFE`'s expansion → Clang sees the macro origin, treats it as an intentional idiom, and suppresses the warning. If you want to silence it in the inline case without rewriting the loop, you have a few options: cast the left side to `void` explicitly — `((void)(tmp = TAILQ_NEXT(dfl, node)), 1)` — which signals to Clang that the discard is intentional, or use a pragma to locally disable `-Wcomma`, or just use the macro (which is the idiomatic approach for TAILQ iteration anyway).
