[PATCH] D146773: [-Wunsafe-buffer-usage] Make raw (ungrouped) warnings a bit more verbose.

Artem Dergachev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon May 15 17:07:48 PDT 2023


NoQ added inline comments.


================
Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11786
+  "%select{"
+    "unsafe operation on raw pointer in expression|"
+    "unsafe arithmetic on raw pointer|"
----------------
malavikasamak wrote:
> NoQ wrote:
> > The first mode doesn't show up in any tests and it's probably dead code at this point.
> What do you think of specifying the variable name in these warnings? It could be helpful when there are more than one DREs in a statement.  
These warnings are emitted only when we *cannot* identify the variable; either because it's not there at all, or we don't know how to find it. If we could figure out the variable, we'd be emitting `warn_unsafe_buffer_variable` instead. IIRC, in all of the provided test cases the operand isn't a DRE.

That said, I totally agree that it's a great idea to try a few other things to point out the specific subexpression, even if we don't connect the warning gadget to a variable. Say, we can try to blame `MemberExpr`s or `CallExpr`s the same way we blame DREs, and include their name in the warning. I'll try a few things real quick and see how bad it gets.

Note that these are also the things for which we may eventually start providing constructive solutions. Say, an unsafe operation on `CallExpr` can be a reason to autofix the callee to return a `std::span`. So hopefully these warnings will eventually be replaced by better warnings in more and more cases.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146773/new/

https://reviews.llvm.org/D146773



More information about the cfe-commits mailing list