[PATCH] Enhanced ignored-qualifiers checks for restrict
richard at metafoo.co.uk
Mon Oct 20 14:17:00 PDT 2014
First off, more warnings for dubious uses of `restrict` seem valuable to me. The two warnings you suggest seem like good ideas. Some thoughts:
I don't think cast expressions are the right thing to target here. The same issue applies to compound literals, new-expressions, and so on. `restrict` only has meaning when used in "a declaration of an ordinary identifier that provides a means of designating an object P", so perhaps we should warn on it (at least at the top level) in all cases where it's not part of such a declaration (and can't be indirectly part of a declaration, such as if it's in a typedef or template argument).
Taking the address of a `restrict`-qualified pointer has weird semantics, and perhaps deserves a warning. For instance:
int *restrict a = &...;
int **p = &a;
*a = 1;
int k = **p;
... is fine, even though `a` is accessed through a non-`restrict`-qualified pointer, because `*q` is based on `a`.
Similarly, declaring an object of a type that has a non-top-level `restrict` qualifier also has weird semantics, and we should perhaps warn on that.
Perhaps we should also warn on copying a `restrict`-qualified pointer to a non-`restrict`-qualified pointer, since that also seems like a very common error.
More information about the cfe-commits