Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

RFE: trivial, non-IPA [cm]alloc / free checking #4398

Open Quuxplusone opened 15 years ago

Quuxplusone commented 15 years ago
Bugzilla Link PR3950
Status NEW
Importance P enhancement
Reported by John Engelhart (john.engelhart@gmail.com)
Reported on 2009-04-06 07:54:55 -0700
Last modified on 2010-02-22 12:50:54 -0800
Version unspecified
Hardware Macintosh MacOS X
CC llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also
Request For Enhancement

Add a check to clang that can catch the following:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void demo(void);

int main(int argc, char *argv[]) {

  return(0);
}

void demo(void) {
  char *buffer = malloc(1024);
  memset(buffer, 0, 1024);

  /* do stuff */

  /* Trivial check only: iff buffer can not escape demo(), check for a corresponding free(buffer). */

}

Nothing complicated, no IPA analysis, just the simplest possible check where
clang can reason that 'buffer' can never possibly escape so a free() should
(almost certainly) be present inside demo().   It would be even better if it
could do some flow sensitive analysis and flag when there is a chance that a
free() might not be called.
Quuxplusone commented 15 years ago

I remembered something else that I forgot to include: 'Use after free()' checking. After a pointer has been free()d, perform analysis to see if the now 'dead' pointer is used again, at least until it is given a new valid value (ie, p = NULL;).

Also semi-related, it would be nice if 'stack frame local' pointers could be tracked to make sure that they do not live past the lifetime of the current stack frame. I suspect this is most likely to occur with something like 'alloca()'- users who aren't familiar with the details of alloca may inadvertently allow the pointer returned by alloca() to live past the point where the current function returns.