Xazax-hun wrote:

> It's probably a good thing for storage locations to have types (because we 
> want to be able to model the dynamic type of an object), but this probably 
> means that we want to model addresses separately from storage locations.

Our knowledge of the dynamic type might change during the analysis. Consider 
the following snippet:

```
void f(Base* b)
{
  if (dynamic_cast<Derived*>(b)) {
    // Here, we know that the dynamic type is (a subclass of) Derived
  }
}
``` 

So, we either need to mutate storage locations, or we need to store the dynamic 
types on the side. The Clang Static Analyzer (CSA) is doing the latter. While 
CSA currently has types associated with the storage locations, we are 
considering undoing this decision and make storage locations only represented 
by sizes and offsets. We plan to always rely on the AST to determine the static 
types, and use a data structure on the side to track the dynamic type 
information. 

That being said, for some frameworks having typed storage locations might be a 
good idea, it is just not obvious to me where is the sweet spot and it will 
need careful consideration. (And as far as I understand, we are not even sure 
whether we want to switch to a different representation like access paths in 
the future.) 

> But all of this would be a major undertaking, I think.

Absolutely agree. The Clang Static Analyzer still has problems with type casts 
in some cases, it is a really challenging problem. That being said, the CSA is 
already immensely useful even with the partial modeling it has, so this is 
probably one of the less pressing problems to solve in the near/medium term. 

https://github.com/llvm/llvm-project/pull/75170
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to