[cfe-dev] CFGElement changes and initializers addition (with patch)

[Ted Kremenek]

On Aug 23, 2010, at 7:44 PM, Zhongxing Xu wrote:

> On Tue, Aug 24, 2010 at 10:41 AM, Zhongxing Xu <xuzhongxing at gmail.com> wrote:
>> 2010/8/20 Ted Kremenek <kremenek at apple.com>:
>>> On Aug 19, 2010, at 11:34 PM, Marcin Świderski wrote:
>>> 
>>>> Location where the destructor was called won't be needed much I suppose. Instead of explicitly giving this position we could provide means of calculating it. If this would be 'kay I think that I can squeeze everything into one PointerIntPair.
>>> 
>>> It will be needed by analyzer diagnostics.  As long as we can reconstruct it when necessary that's fine by me.
>>> 
>>>> 
>>>> One thing that would be needed and could be questionable (I think) would be end of scope element. This element wouldn't have start of scope element counterpart, and it would be used only if sequance of destructors for automatic objects would not end with block termination statement. CFG clients would have to ignore it always as it would be of no use to them.
>>> 
>>> I'm not quite certain what this means.  We can have a block that contains a bunch destructor calls with a single successor to the block in the outer scope.  An explicit "end scope element" isn't strictly needed.
>>> 
>> 
>> Sorry for the late reply. There is a case where we need explicit scope
>> delimiters. We need them to detect resource leaks accurately. Consider
>> code:
>> 
>> void f() {
>>  {
>> 
>>  }
>> 
>> }
>> 
> 
> Sorry, I mistakenly pressed 'send' button.
> 
> void f() {
>  {
>      int *p = malloc(4);
>  }
>  ...
> }
> 
> Without a scope delimiter, we can only detect that the block pointed
> to by 'p' is leaked when getting to the end of 'f'. That's far from
> where it happened.

I disagree.  We use the live variables analysis now in the ObjC retain-release checker to exactly point to the place in the code where an object was leaked.  Adding a scope delimited doesn't help us at all.

Consider:

void f () {
  int *q;
  {
     int *p = malloc(4);
     q = p;
  }
  ...
  last_use(q);
  ...
}

In this case the memory is leaked after 'last_use(q)'.

Where the scope delimiter may help is in cases like this:

void g() {
  int *q;
  {
     int x;
     p = &x;
  }
  *q = 0;  // BAD
}

In this case, we can accurately model in the analyzer when the VarRegion(x) is no longer valid.  That said, I don't think we need to model scopes in the CFG to capture this.  When analyzing a path, we can have a notion of the current scope.  If the scope for 'x' isn't in that scope chain, it is no longer valid.  We don't need extra CFG support for that.