<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 10, 2011, at 7:22 PM, Jordy Rose wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Hi, Ted and Zhenbo. All of this seems very interesting to me too; currently, a function call throws an awful lot of the analyzer's carefully constructed constraints out the window. I just wanted to add that it's probably possible to make a pessimistic function summary mechanism. That is, rather than assuming a function summary models /all/ salient behavior of a function, it can simply make guarantees about certain variables, or add certain constraints, without promising anything else.<br><br>Say, perhaps, that the only "summary" information we have is that if a length parameter is zero, the buffer parameter doesn't need to be invalidated. (I have no idea how we'd represent that.) That means we can go ahead and invalidate any other regions, globals, etc. as usual, but we can still take advantage of the information we /do/ have.<br></span></blockquote></div><div><br></div><div>Hi Jordy,</div><div><br></div><div>In my own words, I'll generalize a bit what you are suggesting.</div><div><br></div><div>One aspect of summaries is that they should model what pieces of memory are modified. A perfect summary would require no region invalidations, as it would just model the modifications directly. A less perfect summary would say "I know this part of memory *could* be modified, but I don't know what the value is." The least perfect summary assumes that all memory can be touched.</div><div><br></div><div>Conceptually what we have now is a summary-based analysis where we always use the most conservative summary. So we already have a summary-based analysis, but it isn't general, and it assumes the most pessimistic results possible.</div><div><br></div><div>So what you are suggesting are summaries that don't explicitly model all possible memory modifications that a function could make, but a conservative estimate (but more precise than what we currently have) of how memory could be modified. To do this, we need to make region invalidation a declarative effect in the summary (just like any other changes the summary models), which ExprEngine then explicitly performs when applying the summary. As part of this, we would just need to make "region invalidation" in the summary dependent on value constraints, just like any other aspect of a summary. One way to do this would be to store region invalidation information literally in a GRState (that would be used to construct a summary). We could (for example) put this in the GRState's GDM, and provide an API for clients to store region invalidation constraints in the GRState. This would allow checkers with domain-specific knowledge of a function to model these region invalidation constraints (in the absence of more perfect summary information).</div><div><br></div><div>Ted</div></body></html>