[cfe-dev] Iterator Checkers: Understanding Bindings

Aleksei Sidorin via cfe-dev cfe-dev at lists.llvm.org
Thu May 12 02:08:56 PDT 2016


Hello Adam.

The main problem with iterators is that they may be a result of complex 
inline-analyzed functions. Relying on the internal structure of returned 
SVal doesn't seem to be a good idea. According to my experience, the 
best approach here is just to consider it as something that has the 
required type.

Note that working with iterators in CSA is complicated enough and I'm 
not even pretend for the good knowledge. Just sharing some experience.
> I think I am on the good path to create iterator checkers for the Clang Static Analyzer. I already executed some experiments successfully, however to do that I needed to "hack" the infrastructure. Now the next step is to create a proper solution instead of the hacking which is unacceptable and would probably brake the system.
>
> My first iterator checker is a very simple checker that tries to recognize cases where an iterator is dereferenced or incremented past its end. To do that I first catch the symbolic value of calls to end() functions that return an iterator type. At this point (checkPostCall) the return value is symbolic which is good. The next step is to post-check comparisons but here I get a temporary instead. The good news is that this temporary is default bound to the same symbol I got from the return value of end(). The bad news is that this default binding is buried and irretrievable in the current Static Analyzer core.
You may need something like checkTemporaryValue() callback which is 
implemented but not currently contributed to upstream (sorry for that). 
It may be used to transmit information related to temporary values while 
doing analysis in your checker before the related information is removed 
from the state. You can check our github project and 
BasicStringBoundChecker to see the implementation of this callback and 
its usage. If it is what you need, we'll hurry with upstreaming.
https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/StaticAnalyzer/Checkers/BasicStringBoundChecker.cpp
> The key function to retrieve binding is RegionStoreManager::getBinding() in RegionStore.cpp. However, this function only retrieves direct bindings. I could not find too much documentation about the two types of bindings, I could only find out the default binding is used for structure members where the members are not direct bound but the structure itself has a default binding. I found nothing about what should happen when retrieving the binding for the structure itself where it only has a default binding.
I'm not sure that getting a binding is something that you really need. I 
have tried to operate with regions directly instead. Could you share 
your work and give some test case? I think I don't fully understand what 
is your question about.
>
> The situation is even worse here. The name of function getBinding() is a bit misleading because it does not even retrieve a direct binding even if it exists.
May be the binding _is_ LazyCompoundVal?
>   In case of structures or class types it creates a lazy compound value even if the binding exists. Why is this behavior? The lazy compound value then can be used to get back the original structure/class, thus the temporary. This is just a round trip and does not help to retrieve the binding, even if this would be a direct binding. After an assignment of the return value to a variable, checking the variable (e.g. as an operand of a pre- or postCall checker) a symbol is of course bound to the variable as well. However in this case the binding could be retrieved if it would be a direct binding, because in this case it is not considered a struct/class anymore but as a variable region.
>
> Could somebody help me to understand why bindings behave this way and what to change to be able to retrieve these default bindings? The are essential for all iterator checkers which are needed by many projects.
> Thank you for your cooperation in advance!
>
> Regards,
>
> Ádám

-- 
Best regards,
Aleksei Sidorin
Software Engineer,
IMSWL-IMCG, SRR, Samsung Electronics




More information about the cfe-dev mailing list