[cfe-dev] Iterator Checkers: Understanding Bindings

Artem Dergachev via cfe-dev cfe-dev at lists.llvm.org
Thu May 12 04:09:20 PDT 2016


RegionStore, as one of the possible implementations of the Store, does 
not explicitly store every binding it can provide. For example, at the 
beginning of the analysis, every variable's value is SymbolRegionValue 
of this variable's region, however this value is not stored as a direct 
binding - it is simply assumed to be there since there's no other 
binding to override this assumption.

Same thing with LazyCompoundVal's - once you ask for an SVal to 
represent a value of a structure-type region R, you get a 
LazyCompoundVal, even if it's not bound to R directly. The original 
symbol (returned by eg. in your case begin() or end()) represents the 
original contents of the structure. However, later the structure may (or 
may not) have its fields changed, that is, other values may (or may not) 
be bound to sub-regions of R. Which means that the original symbol does 
not necessarily describe the value bound to the structure-type region R. 
LazyCompoundVal, on the other hand, always (regardless of other 
bindings) describes the structural value correctly. Moreover, it can be 
constructed without figuring out if there were sub-region bindings - it 
just copies the whole store (which is immutable, and therefore extremely 
cheap to copy). So the analyzer just goes ahead and always creates a 
LazyCompoundVal, without looking if there are any new bindings.

I've seen cases when retrieving the original default symbol made sense 
to me, so i'd agree that an API for that would be useful. However, from 
above it should be obvious that it's not how the store should normally 
operate; you start digging into implementation details here. This symbol 
can be used for identifying the instance of the object (and all copies 
of it), but the object could have completely changed since this symbol 
was born. Because iterators don't seem to change through bindings, this 
might be a way to go.

Hope this helps.



More information about the cfe-dev mailing list