rsmith added a comment.
I think we need some documented guidelines on what is and is not an appropriate
warning for Clang. I think it's reasonable to warn in cases where we are
confident that the code means something other than what the programmer or a
later reader is likely to expect; it's less obvious to me whether this warning
fits that categorization: while a lot of people are confused by C/C++'s
multi-declarator declaration rules, there are also many people who are not, and
who use this kind of coding pattern (if you look at, say, the ffmpeg source
code, you can find all sorts of things like this: `char *p,
buf[AV_HASH_MAX_SIZE * 2 + 64] = { 0 };`, `int *fds = NULL, fdsnum, fdsidx;`,
`int *tmp, i, len;`, `int *p, vmax, v, n, i, j, k, code;`, and so on).
Generally in the cases where we do accept such warnings on valid code that
might nonetheless mean something different from what was intended, or be
misread by people who have not internalized the relevant language rules, there
is a simple syntactic workaround that suppresses the diagnostic, and we suggest
that workaround in a note attached to the warning. (For example, for assignment
in an `if` condition, we suggest adding another pair of parentheses, and
likewise we suggest adding parentheses for an `&&` expression as an operand of
an `||` expression.) Is there a similar syntactic workaround we can suggest
here? For example, would
int *ptr, (a), b, c;
... suppress the warning for `a`?
https://reviews.llvm.org/D52791
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
