[cfe-dev] Iterator Checkers: Understanding Bindings

[Ádám Balogh via cfe-dev]

Hello,

Thank you for your quick reply (both Artem and Aleksei). It was very useful. Now I understand that there are two very different needs. The first need is what most checkers require and the Static Analyzer currently satisfies is that structures are analyzed deeply. However, what we need here is to handle some structures in our checker as opaque objects. I think iterator checkers are not the only one with such need, some checkers, e.g. STL, Boost or some project-specific checkers to be developed in the future may have similar needs.

If I understand it correctly, we need to implement a new function in RegionStoreManager that retrieves the raw binding for an SVal. This function must also be declared in StoreManager class as a pure virtual function. This function must be able to retrieve default bindings as well. Should it try to retrieve a direct binding first? And how to call that function? getRawBinding()? Or maybe getBindingForOpaqVal()?

Regards,

Ádám

-----Original Message-----
From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Artem Dergachev via cfe-dev
Sent: 2016. május 12. csütörtök 13:09
To: cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] Iterator Checkers: Understanding Bindings

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.
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev