[PATCH] [analyzer][Review request] Better modelling of memcpy by the CStringChecker (PR16731)

Антон Ярцев anton.yartsev at gmail.com
Mon Oct 28 18:59:24 PDT 2013

  It is the analyzer core (RegionStoreManager::invalidateRegions()) that perform common invalidation of a region as well as it's subregions/indirect regions, traits are used to handle exceptions from the common invalidation logic. Thus marking a region with TK_PreserveContents we prevent the contents of the particularly this region (not subregions/indirect regions) from being invalidated by the core if invalidation touches this region. All the subregions/indirect regions are invalidated in default way.

  The similar situation with the pointer escape - normally we either call pointer escape callback for an any region/symbol, touched by the invalidation of a top level region or do not call pointer escape callback for either of the regions touched by that invalidation. For now we deviate from this rule only in the case, when we artificially model an impact of the call to 'memcpy' (and several similar library copy functions) on it's source and destination buffers.

  Calling ConstPointerEscape with TK_SuppressEscape and !TK_PreserveContents means that the checkConstPointerEscape should not be fired for a given region for two reasons - TK_SuppressEscape tells that the escape of a given region is suppressed (currently by the user) and !TK_PreserveContents tells that a given symbol is the matter of a regular pointer escape.

  If I understand correctly, invalidation and escape is already split into at least three callbacks: checkRegionChanges for invalidation and checkPointerEscape/checkConstPointerEscape for escape.

  I think it is currently no need to give the user an ability to invalidate/escape a particular region/symbol passing the common invalidation/escape mechanism.


More information about the cfe-commits mailing list