<br><br><div class="gmail_quote">On Sat, Feb 21, 2009 at 3:13 PM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On Feb 20, 2009, at 10:29 PM, Zhongxing Xu wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Ted, consider this code:<br>
void* myfunc();<br>
<br>
void f13() {<br>
  char** array;<br>
  array = myfunc();<br>
  char *p = array[0];<br>
  char c = *p;<br>
}<br>
<br>
Currently clang crashes on this code. We conjured a symbol for call to myfunc() with type void*. But when we dereference<br>
*p, clang expects the type of the symbol to be char**. We does nothing when casting void* to char**.<br>
This patch tries to solve this problem specifically. What I want to do essentially is to change the symbol's type when doing casting.<br>
But as symbols are immutable, I just created a new symbol with the right type.<br>
</blockquote>
<br>
<br></div>
Hi Zhongxing,<br>
<br>
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:</blockquote>
<div><br>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?<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
(a) Generate a ton of symbols that will be immediately thrown away.  This is a performance concern.<br>
<br>
(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.</blockquote><div><br>No. In my patch, the new symbol is created before it is saved to array.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
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.</blockquote>
<div><br>Completely agree. This is my thought. I think I just didn't implement it right.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Thoughts?</blockquote><div><br><br></div></div><br>