[PATCH] D68725: [analyzer] MemoryBlockRegion: Generalize AllocaRegion
Artem Dergachev via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Oct 29 16:56:34 PDT 2019
NoQ added a comment.
In D68725#1724213 <https://reviews.llvm.org/D68725#1724213>, @Charusso wrote:
> In D68725#1722136 <https://reviews.llvm.org/D68725#1722136>, @NoQ wrote:
>
> > Even if `AllocaRegion` didn't store the expression, any path-sensitive checker for which such region is "interesting" would have to implement a bug visitor to display the allocation site. Such visitor automatically knows the location of the `alloca()` expression and can emit the necessary fixits.
>
>
> The rational behind the latter to make `CStringChecker` as simply `StringChecker`, with modelling the concept: `str.size()` is the dynamic size behind `VarRegion(str)`.
We already have `SymbolMetadata` for that purpose. If you want, you can model the inner buffer of a `std::string` as a `SymbolMetadata` of type `char *` associated with the region of the `std::string`; in this case the string's //capacity// is the extend of the symbolic region associated with `SymbolMetadata` and the string's //length// is `CStringChecker`'s existing `SymbolMetadata` of type `size_t` associated with the same symbolic region.
I don't particularly love `SymbolMetadata` because i believe it should be associated with symbols rather than with regions-and-points (eg., introduce a symbolic identity for the `std::string` that gets preserved on copies and associate `SymbolMetadata` with that identity).
But i believe that we already have enough concepts and tools here, there's no need to introduce more of them.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D68725/new/
https://reviews.llvm.org/D68725
More information about the cfe-commits
mailing list