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

[Ted Kremenek]

On Aug 23, 2010, at 8:18 PM, Jordy Rose wrote:

> 
> On Tue, 24 Aug 2010 10:44:42 +0800, Zhongxing Xu <xuzhongxing at gmail.com>
> 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:
>>>>> 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() {
>>  {
>>      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.
> 
> Unless we have destructor nodes for /all/ objects, whether the destructor
> is trivial or not.
> 
> (Not trying to push either side, just presenting another possibility.)

That's a generalized solution, but I think that's overkill.  Very few analyses will care about that, and the analyses that I can think of that need to reason about the lifetime of stack objects that don't have destructors can recreate the information they need in a fairly straightforward way using LocationContexts and the notion of the current scope.  I don't think CFG support is needed here.