AaronBallman wrote: > > Is this still worth adding here? I didn't see an equivalent in clang's > > -Wall. > > Indeed Clang is missing this check in -Wall. For parity with GCC it probably > makes sense to add it to -Wall as well instead of being a clang-tidy check. > What do you think @AaronBallman ?
In general, this requires dataflow analysis to get a low false-positive rate, which is typically handled via static analysis or a CFG-based analysis (which are expensive to construct for `-Wall` and thus usually opt-in, but we do have some such checks that have crept in so there is precedence). Ideally, I think this check would either live in Clang under an opt-in analysis warning flag (similar to implicit fallthrough checks) or in the Clang static analyzer (CC @steakhal @haoNoQ @Xazax-hun for additional opinions). If we did that, I think this check should be generalized a bit more. 1) We could have a `restrict`-based check for any APIs with pointers marked `restrict`. 2) We could handle C library functions specially: `sprintf` and friends, `mbstowcs`, `wcstombs`, `memcpy`, `memccpy`, `strcpy`, etc. https://github.com/llvm/llvm-project/pull/114244 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
