[PATCH] D137348: [-Wunsafe-buffer-usage] Introduce an abstraction for fixable code patterns.

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Nov 29 08:35:26 PST 2022


aaron.ballman added inline comments.


================
Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:63
+
+  Gadget(Kind K) : K(K) {}
+
----------------
NoQ wrote:
> aaron.ballman wrote:
> > Should this be an explicit constructor? (Same question applies below to derived classes as well.)
> What's the value of making it `explicit` given that it's an abstract class that can't be constructed directly anyway?
None, I had missed that this was an abstract class and forgot to delete the comment here on the base class. It does apply to the (non-abstract) derived classes though.


================
Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:113
+      : UnsafeGadget(Kind::Increment),
+        Op(Result.Nodes.getNodeAs<UnaryOperator>("op")) {}
+
----------------
NoQ wrote:
> aaron.ballman wrote:
> > Should we make a `static constexpr const char *` for these strings so we can give it a name and ensure it's used consistently?
> I think it makes perfect sense to have different bind-names in different classes. They don't all correspond to the same role the bound expression plays.
Sorry, I was unclear. I meant a private data member of `IncrementGadget` so that the constructor and the `matcher()` functions use a named constant rather than a string literal.


Repository:
  rC Clang

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

https://reviews.llvm.org/D137348



More information about the cfe-commits mailing list