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

[Marcin Świderski]

2010/8/24 Jordy Rose <jediknil at belkadan.com>

>
> 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.)


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?:

void f() {
  goto label;
  {
    int* p = malloc(4);
label:
    ...
  }
  ...
}

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?

If that is the case I understand that that what is to be done is:
- Adding implicit scopes for selection and iteration statements in case the
body is not a compound statement but declares some variables,
- Not adding EndScope delimiter if scope ends with jump as it would produce
unnecessary unreachable CFGBlock.

I think that while I'm working on C++ initializers/destructors I could also
add this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100824/a931e1c8/attachment.html>