[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