<div dir="ltr">Jordan,<div><br></div><div>Thanks, I really appreciate the reply. Based on the above example it definitely appeared as though only immediate subexpressions were available, but obviously that wasn't what I had expected and so it's nice to have confirmation that it's generally the case.</div>
<div><br></div><div>This was more or less experimentation that didn't pan out. I'm still familiarizing myself with the engine and its capabilities and so when I ran into this I wasn't sure if I was doing something wrong or that's how it was meant to be. Originally, I had assumed that when more or less in the same context, I would be able to successfully evaluate the same set of expressions.</div>
<div><br></div><div>-Mike</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 28, 2014 at 9:54 AM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi, Michael. The analyzer tracks the values of expressions in a map from Expr* (actually Stmt*) to SVal called the Environment, which is part of the ProgramState. In order to keep the Environment small, expressions that have already been evaluated are cleared out of the current state at certain points in the program. That means you can't rely on being able to get the value of anything other than your immediate subexpressions.</div>
<div><br></div><div>The next logical step is to try to move backwards through the ExplodedGraph until you find a node that still references the expression you want to look at. However, <i>that's</i> not guaranteed to be present, either: ExplodedNodes are trimmed out of the graph unless they are "interesting" in some way (for example, they have been generated by a checker and may be referenced in a bug report later). So you can't rely on <i>any</i> node still referencing the value of a particular expression several steps down the line—only immediate subexpressions.</div>
<div><br></div><div>Is there anything in particular you're trying to do here, or was it just experimentation that didn't pan out?</div><div><br></div><div>Jordan</div><div dir="ltr"><br></div><br><div><div><div class="h5">
<div>On Feb 27, 2014, at 16:17 , Michael Katelman <<a href="mailto:katelman@gmail.com" target="_blank">katelman@gmail.com</a>> wrote:</div><br></div></div><blockquote type="cite"><div><div class="h5"><div dir="ltr">
I'm having some trouble understanding exactly under what circumstances I can construct a "known" sval for various expressions.<div><br></div><div>Here's a concrete example that I ran into and was surprised about:</div>

<div><br></div><div>int f(float x){</div><div>  return (int)x;</div><div>}</div><div><br></div><div>int main(int argc, char** argv){</div><div>   int x = -1;</div><div>   f(x);</div><div>   return 0;</div><div>}</div><div>

<br></div><div>I then created a checker that registered for the PreCall check. When checkPreCall was invoked, Call.getArgSVal(0) is unknown, which makes sense to me because the system doesn't reason about floating-point, however, I was surprised that this also results in an unknown value (regardless of it's overall sensibility):</div>

<div><br></div><div>C.getState()->getSVal(dyn_cast<ImplicitCastExpr>(Call.getArgExpr(0)->getSubExpr()))</div><div><br></div><div>Indeed, if I change the definition of f so that it becomes:</div><div><br></div>

<div>int f(int x){</div><div>  return x;</div><div>}</div><div><br></div><div>Then Call.getArgSVal(0) is known and insofar as I can tell should be equivalent to the above in the earlier context. I'd be interested to understand why that's not the case and in general what expressions can be converted to usable svals during the check calls.</div>

<div><br></div><div>Thanks!</div><div><br></div><div>-Mike</div></div></div></div>
_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></blockquote></div><br></div>