[PATCH] [Review request][analyzer] Duplicate '0 size allocation' check from unix.API in unix.Malloc.

[Anna Zaks]

Anton, Can you add the quote from the standard somewhere in the comments explaining the zero allocation warning?


================
Comment at: test/Analysis/malloc-annotations.c:51
@@ -47,1 +50,3 @@
+  int *p = malloc(12);
+  realloc(p,0); // no-warning
 }
----------------
ayartsev wrote:
> Quuxplusone wrote:
> > FWIW, this maybe should give the same warning as `realloc(p,1);` on a line by itself: namely, because the returned pointer is never freed, this code has a memory leak on implementations where `realloc(p,0)` returns a non-null pointer.
> > 
> > If the returned pointer is captured (`q = realloc(p,0);`) and later freed (`free(q);`), there is no bug. It's not unsafe to use the return value of `realloc`; it's perfectly safe and well-defined. The only implementation-defined aspect of `realloc` is whether the returned pointer is null or not. Either way, *using* the returned pointer is fine — it's not like using a freed pointer, which is indeed undefined behavior.
> //FWIW, this maybe should give the same warning as realloc(p,1); on a line by itself: namely, because the returned pointer is never freed, this code has a memory leak on implementations where realloc(p,0) returns a non-null pointer.//
> Agree.
> 
> //It's not unsafe to use the return value of realloc; it's perfectly safe and well-defined. *using* the returned pointer is fine — it's not like using a freed pointer, which is indeed undefined behavior.//
> It's not a safety check, just a warning that there may be an error in the code. The usage of a pointer returned from realloc(p,0) is suspicious, any bytes in the new object have indeterminate values also modifying the contents the returned memory is an error.
> Zero size may be requested by reason of an error when the second parameter to realloc() is a variable.
I don't think we should be warning when free is called on the returned value from realloc(p,0). We should try and stay away from reporting issues that would lead to known false positives. 

We could whitelist various ways the pointer could be dereferenced and warn on those or just not warn on realloc(p,0). (I think passing '0' to other allocation functions would not likely trigger false positives.)

Anton, what do you think?

http://reviews.llvm.org/D6178

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/