[cfe-commits] [patch] cast SymbolVal

[Ted Kremenek]

On Feb 20, 2009, at 10:29 PM, Zhongxing Xu wrote:

> Hi Ted, consider this code:
> void* myfunc();
>
> void f13() {
>   char** array;
>   array = myfunc();
>   char *p = array[0];
>   char c = *p;
> }
>
> Currently clang crashes on this code. We conjured a symbol for call  
> to myfunc() with type void*. But when we dereference
> *p, clang expects the type of the symbol to be char**. We does  
> nothing when casting void* to char**.
> This patch tries to solve this problem specifically. What I want to  
> do essentially is to change the symbol's type when doing casting.
> But as symbols are immutable, I just created a new symbol with the  
> right type.


Hi Zhongxing,

That's understandable, but I still think its not quite the right  
design for the broader problem.  I think we want to do is update the  
type information associated with the symbol, not change the symbol  
itself.  By conjuring up new symbols like this we are going to:

(a) Generate a ton of symbols that will be immediately thrown away.   
This is a performance concern.

(b) Lose a bunch of alias information.  Even in your example we will  
lose the fact that the value stored to 'p' and the value of loaded  
from array[0] are the same.

To me symbols are just names for values.  The type information is just  
a property of the values the symbol represents, just like the  
constraints managed by ConstraintManagers manage a certain kind of  
property on the values of symbols.  I'm completely open to the idea  
that the type information can evolve as the simulation progresses  
(just as constraints do).  Conjuring up new symbols for the same value  
just doesn't feel right, and inherently means we are going to lose  
precision.  In comparison, updating the property of the symbol just  
means we accrue more information as the analysis progresses instead of  
throwing information away.

Thoughts?