rsmith added a comment. In D71714#1792085 <https://reviews.llvm.org/D71714#1792085>, @efriedma wrote:
> To be rigorous, we should perform "pointer" checking for every operation that > performs pointer arithmetic. Then we should perform "lvalue" checking (which > doesn't allow pointers one past the end) in the following places: > > 1. When we take the address of an lvalue. > 2. When we form a reference to an lvalue. > 3. When we perform an lvalue-to-rvalue conversion. > 4. When we perform an assignment to an lvalue. > > This sort of piecemeal approach of recursively looking through arbitrary > expressions seems likely to miss cases. For example, we currently don't > perform checks inside compound literals. I agree that this approach is not good. I'm concerned that your direction might still miss things, though (and it seems to involve a lot of AST traversal, which would be nice to avoid). For example, `__builtin_bitcast` performs a load without an lvalue-to-rvalue conversion, and to be thorough we'd need to special-case it. Perhaps we could instead: - warn immediately when indexing outside [0, N] inclusive - produce a deferred warning when indexing with index N, and diagnose at the end of the expression evaluation context - remove elements from the list of deferred warnings when handling an `&` operator In C at least, that should be correct in all cases. I think it's correct in C++ as well; there are lots more forms of lvalue to walk into in the third step (eg, `&(cond ? x[n] : y[n])` shouldn't warn), but it seems feasible to enumerate. (This would lose the warnings on `*&x[n]`, but I don't think that's a disaster.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71714/new/ https://reviews.llvm.org/D71714 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
