[PATCH] D46823: [analyzer] const init: handle non-explicit cases more accurately

Rafael Stahl via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue May 15 06:44:06 PDT 2018


r.stahl added inline comments.


================
Comment at: lib/StaticAnalyzer/Core/RegionStore.cpp:1650
+
+            // If there is a list, but no init, it must be zero.
+            if (i >= InitList->getNumInits())
----------------
NoQ wrote:
> NoQ wrote:
> > Would this work correctly if the element is not of an integral or enumeration type? I think this needs an explicit check.
> What if we have an out-of-bounds access to a variable-length array? I don't think it'd yield zero.
I'm getting "variable-sized object may not be initialized", so this case should not be possible.


================
Comment at: lib/StaticAnalyzer/Core/RegionStore.cpp:1650-1652
+            // If there is a list, but no init, it must be zero.
+            if (i >= InitList->getNumInits())
+              return svalBuilder.makeZeroVal(R->getElementType());
----------------
r.stahl wrote:
> NoQ wrote:
> > NoQ wrote:
> > > Would this work correctly if the element is not of an integral or enumeration type? I think this needs an explicit check.
> > What if we have an out-of-bounds access to a variable-length array? I don't think it'd yield zero.
> I'm getting "variable-sized object may not be initialized", so this case should not be possible.
I'm having a hard time reproducing this either.


```
struct S {
  int a = 3;
};
S const sarr[2] = {};
void definit() {
  int i = 1;
  clang_analyzer_dump(sarr[i].a); // expected-warning{{test}}
}
```

results in a symbolic value, because makeZeroVal returns an empty SVal list for arrays, records, vectors and complex types. Otherwise it just returns UnknownVal (for example for not-yet-implemented floats).

Can you think of a case where this would be an issue?


https://reviews.llvm.org/D46823





More information about the cfe-commits mailing list