2010/8/24 Jordy Rose <span dir="ltr"><<a href="mailto:jediknil@belkadan.com">jediknil@belkadan.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On Tue, 24 Aug 2010 11:20:20 +0800, Zhongxing Xu <<a href="mailto:xuzhongxing@gmail.com">xuzhongxing@gmail.com</a>><br>
<div><div></div><div class="h5">wrote:<br>
> On Tue, Aug 24, 2010 at 11:18 AM, Jordy Rose <<a href="mailto:jediknil@belkadan.com">jediknil@belkadan.com</a>><br>
wrote:<br>
>><br>
>> On Tue, 24 Aug 2010 10:44:42 +0800, Zhongxing Xu<br>
<<a href="mailto:xuzhongxing@gmail.com">xuzhongxing@gmail.com</a>><br>
>> wrote:<br>
>>> On Tue, Aug 24, 2010 at 10:41 AM, Zhongxing Xu <<a href="mailto:xuzhongxing@gmail.com">xuzhongxing@gmail.com</a>><br>
>>> wrote:<br>
>>>> 2010/8/20 Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>>:<br>
>>>>> On Aug 19, 2010, at 11:34 PM, Marcin Świderski wrote:<br>
>>>>>> One thing that would be needed and could be questionable (I think)<br>
>>>>>> would be end of scope element. This element wouldn't have start of<br>
>>>>>> scope element counterpart, and it would be used only if sequance of<br>
>>>>>> destructors for automatic objects would not end with block<br>
>> termination<br>
>>>>>> statement. CFG clients would have to ignore it always as it would<br>
be<br>
>> of<br>
>>>>>> no use to them.<br>
>>>>><br>
>>>>> I'm not quite certain what this means. We can have a block that<br>
>>>>> contains a bunch destructor calls with a single successor to the<br>
block<br>
>>>>> in the outer scope. An explicit "end scope element" isn't strictly<br>
>>>>> needed.<br>
>>>>><br>
>>>><br>
>>>> Sorry for the late reply. There is a case where we need explicit<br>
scope<br>
>>>> delimiters. We need them to detect resource leaks accurately.<br>
Consider<br>
>>>> code:<br>
>>><br>
>>> void f() {<br>
>>> {<br>
>>> int *p = malloc(4);<br>
>>> }<br>
>>> ...<br>
>>> }<br>
>>><br>
>>> Without a scope delimiter, we can only detect that the block pointed<br>
>>> to by 'p' is leaked when getting to the end of 'f'. That's far from<br>
>>> where it happened.<br>
>><br>
>> Unless we have destructor nodes for /all/ objects, whether the<br>
destructor<br>
>> is trivial or not.<br>
>><br>
>> (Not trying to push either side, just presenting another possibility.)<br>
>><br>
><br>
> You mean creating a destructor node for 'p' in this case?<br>
<br>
</div></div>Yeah. I guess I don't mean "all objects" but "all variables plus all<br>
temporaries with non-trivial destructors". I figure checkers are going to<br>
be able to visit destructor nodes as well, so this would be almost as good<br>
as a VisitEndScope. (Which itself is more powerful than VisitEndAnalysis,<br>
as you pointed out.)</blockquote><div><br></div><div>Implicit call to C++ destructor is part of control flow of a program and it should have representation in CFG. However variable going out of scope is not IMO, so I don't think that this would be a good idea. And for C we can jump over variable initialization. So should we create destructor node for 'p' in this case also?:</div>
<div><br></div><div>void f() {</div><div> goto label;</div><div> {</div><div> int* p = malloc(4);</div><div>label:</div><div> ...</div><div> }</div><div> ...</div><div>}</div><div><br></div></div>As I understand for delimiter approach we need StartScope and EndScope delimiters to know where in CFG we enter and leave scopes but without jump. In case of jumps it would be for client to deduce what scopes will be left and entered? I mean we don't need any more information in CFG for this?<div>
<br></div><div>If that is the case I understand that that what is to be done is:</div><div>- Adding implicit scopes for selection and iteration statements in case the body is not a compound statement but declares some variables,</div>
<div>- Not adding EndScope delimiter if scope ends with jump as it would produce unnecessary unreachable CFGBlock.</div><div><br></div><div>I think that while I'm working on C++ initializers/destructors I could also add this.</div>
<meta charset="utf-8">