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

[Jordy Rose]

On Tue, 24 Aug 2010 11:20:20 +0800, Zhongxing Xu <xuzhongxing at gmail.com>
wrote:
> On Tue, Aug 24, 2010 at 11:18 AM, Jordy Rose <jediknil at belkadan.com>
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.)
>>
> 
> You mean creating a destructor node for 'p' in this case?

Yeah. I guess I don't mean "all objects" but "all variables plus all
temporaries with non-trivial destructors". I figure checkers are going to
be able to visit destructor nodes as well, so this would be almost as good
as a VisitEndScope. (Which itself is more powerful than VisitEndAnalysis,
as you pointed out.)