[PATCH] D48436: [analyzer][UninitializedObjectChecker] Fixed a false negative by no longer filtering out certain constructor calls

Artem Dergachev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jul 12 12:43:50 PDT 2018


NoQ added a comment.

> A call to `Derived::Derived()` previously emitted no warnings. However, with these changes, a warning is emitted for `Base::a`.

Yep, a heuristic to skip implicit constructor declarations during analysis and make the first explicit constructor responsible for initializing its bases/fields that have been constructed via autogenerated constructors seems reasonable. With that i guess you'll still have to deep-scan fields and bases, which prevents us from simplifying our code. I'll think about that a bit more; it might be worth it to track such deferred subregions in a state trait and drain it whenever we pop back to an explicit constructor.



================
Comment at: lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp:681-689
+    Optional<nonloc::LazyCompoundVal> OtherObject =
+        getObjectVal(OtherCtor, Context);
+    if (!OtherObject)
+      continue;
+
+    // If the CurrentObject is a field of OtherObject, it will be analyzed
+    // during the analysis of OtherObject.
----------------
It seems safer to look at `CXXConstructExpr::getConstructionKind()`.

Taking a `LazyCompoundVal` and converting it back to a region is definitely a bad idea because the region within `LazyCompoundVal` is completely immaterial and carries no meaning for the value represented by this `SVal`; it's not necessarily the region you're looking for.


https://reviews.llvm.org/D48436





More information about the cfe-commits mailing list