[cfe-dev] Potentially expensive analysis for missing `[]` in delete expression

Jordan Rose jordan_rose at apple.com
Tue Jul 8 14:34:29 PDT 2014


The static analyzer does have this check:

<stdin>:3:5: warning: Memory allocated by 'new[]' should be deallocated by
      'delete[]', not 'delete'
    delete a;
    ^~~~~~~~

...but only if it can see both the allocation and deallocation sites in the same path.

Jordan

On Jul 8, 2014, at 10:17 , Rafael Auler <rafaelauler at gmail.com> wrote:

> This is an interesting analysis that would really help a lot of people. However, if the analysis intend to be truly accurate, I think it should be implemented in the static analyzer. 
> 
> For example:
> 
> if (cond)
>   a = new int[5];
> else
>   a = (int*) malloc(sizeof(int)*5);
> 
> would easily trick a CFG-based analysis because it can't know at compile-time whether cond is true or false.
> 
> Nevertheless, I still believe that a front-end analysis can help in simpler cases, but we can't expect to be 100% accurate.
> 
> 
> On Tue, Jul 8, 2014 at 1:57 PM, Ismail Pazarbasi <ismail.pazarbasi at gmail.com> wrote:
> Hi,
> 
> During a demo, audience caught that I forgot [] in delete expression. clang didn't warn about it. I was wondering whether this is due to the cost of analysis. My sample was something like:
> 
>   class A {
>     int *a;
>   public:
>     A() : a(new int[5]) { }
>     ~A() { delete /*[]*/ a; }
>   };
> 
> but following doesn't seem like to analyze missing [] either:
> 
>   % clang++ -fsyntax-only -x c++ -pedantic -Wall -Wextra -
>   void f() {
>     int *a = new int[5];
>     delete a;
>   }
>   %
> 
> Is this analysis omitted due to performance concerns or simply an oversight?
> 
> Analyzing my sample requires clang to analyze all ctor-initializers, then in-class initializers, to check whether member was new[]'ed each time it sees delete expression where pointee is a MemberExpr. For the latter case, I think checking whether VarDecl initialized with new[] is enough. Did I get this right? I already have a patch for this, but I didn't test its performance impact on a sufficiently large code base. Do we have previous implementation experience with this?
> 
> Ismail
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140708/e48cb638/attachment.html>


More information about the cfe-dev mailing list