[cfe-commits] [patch] cast SymbolVal

[Zhongxing Xu]

On Sat, Feb 21, 2009 at 3:13 PM, Ted Kremenek <kremenek at apple.com> wrote:

>
> 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:


I completely agree with that we should update the type information instead
of creating a new symbol. But as symbols are immutable, how can we do this?
A conjured symbol has three parts of information: Stmt*, QualType, and a
Count. Should I take the same Stmt* and Count but with the new QualType to
create the new symbol?


>
>
> (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.


No. In my patch, the new symbol is created before it is saved to array.


>
>
> 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.


Completely agree. This is my thought. I think I just didn't implement it
right.


>
>
> Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20090221/2c85f5b7/attachment.html>