[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