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

Zhongxing Xu xuzhongxing at gmail.com
Mon Aug 23 20:20:20 PDT 2010


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?




More information about the cfe-dev mailing list