[PATCH] D69540: [analyzer] DynamicSize: Remove 'getExtent()' from regions
Artem Dergachev via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Oct 29 16:45:25 PDT 2019
NoQ added inline comments.
================
Comment at: clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1253-1255
+ MemRegionManager(ASTContext &c, llvm::BumpPtrAllocator &a, SValBuilder &SVB,
+ SymbolManager &SymMgr)
+ : Ctx(c), A(a), SVB(SVB), SymMgr(SymMgr) {}
----------------
This looks like a layering violation to me. It's not super important, but i'd rather not have `MemRegion` depend on `SValBuilder`.
Can we have `getStaticSize()` be a method on `SValBuilder` instead? Or simply a standalone static function in `DynamicSize.cpp`? 'Cause ideally it shouldn't be called directly.
================
Comment at: clang/lib/StaticAnalyzer/Checkers/BuiltinFunctionChecker.cpp:95-99
+ DefinedOrUnknownSVal DynSize = getDynamicSize(state, R);
+
+ DefinedOrUnknownSVal DynSizeMatchesSizeArg =
+ svalBuilder.evalEQ(state, DynSize, Size.castAs<DefinedOrUnknownSVal>());
+ state = state->assume(DynSizeMatchesSizeArg, true);
----------------
As the next obvious step for the next patch, i suggest replacing `evalEQ()` with some sort of `setDynamicSize()` here.
================
Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:1074
std::tie(StateWholeReg, StateNotWholeReg) =
- State->assume(svalBuilder.evalEQ(State, Extent, *SizeNL));
+ State->assume(svalBuilder.evalEQ(State, SizeDV, *SizeNL));
----------------
And here.
================
Comment at: clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp:1413
svalBuilder.getArrayIndexType());
- DefinedOrUnknownSVal extentMatchesSize = svalBuilder.evalEQ(
- State, Extent, SizeInBytes.castAs<DefinedOrUnknownSVal>());
- State = State->assume(extentMatchesSize, true);
+ DefinedOrUnknownSVal DynSizeMatchesSize = svalBuilder.evalEQ(
+ State, DynSize, SizeInBytes.castAs<DefinedOrUnknownSVal>());
----------------
And here.
================
Comment at: clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp:1547
+ DefinedOrUnknownSVal DynSizeMatchesSize =
+ svalBuilder.evalEQ(State, DynSize, *DefinedSize);
----------------
And here.
================
Comment at: clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp:176
DefinedOrUnknownSVal sizeIsKnown =
- svalBuilder.evalEQ(state, Extent, ArraySize);
+ svalBuilder.evalEQ(state, DynSize, ArraySize);
state = state->assume(sizeIsKnown, true);
----------------
And here.
================
Comment at: clang/lib/StaticAnalyzer/Core/DynamicSize.cpp:29-30
+ const MemRegion *MR) {
+ if (const DefinedOrUnknownSVal *Size = State->get<DynamicSizeMap>(MR))
+ return *Size;
+
----------------
For now the map is always empty, right? Maybe we should remove the map until we actually add a setter.
================
Comment at: clang/lib/StaticAnalyzer/Core/MemRegion.cpp:692-693
+ case MemRegion::FunctionCodeRegionKind: {
+ QualType Ty = cast<TypedRegion>(SR)->getDesugaredLocationType(Ctx);
+ return getTypeSize(Ty, Ctx, SVB);
+ }
----------------
This code doesn't make much sense; it'll return a pointer size, which has nothing to do with the size of the region.
================
Comment at: clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:158
// symbols to use, only content metadata.
- return nonloc::SymbolVal(SymMgr.getExtentSymbol(FTR));
+ return FTR->getMemRegionManager().getStaticSize(FTR);
----------------
Charusso wrote:
> That is the breaking test's code, which is super wonky. I cannot understand what is the rational behind this concept.
Your new code would return a concrete integer here:
```lang=c++
case MemRegion::FunctionCodeRegionKind: {
QualType Ty = cast<TypedRegion>(SR)->getDesugaredLocationType(Ctx);
return getTypeSize(Ty, Ctx, SVB);
}
```
Previously it was a symbol.
That said, the original code looks like a super gross hack: they used an extent symbol not because they actually needed an extent, but because they didn't have a better symbol to use :/ I guess you should just keep the extent symbol for now :/
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69540/new/
https://reviews.llvm.org/D69540
More information about the cfe-commits
mailing list