[PATCH] D52791: [Diagnostics] Check for misleading pointer declarations
Richard Smith - zygoloid via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Oct 3 17:24:48 PDT 2018
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
More information about the cfe-commits
mailing list