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

[Антон Ярцев]

================
Comment at: lib/StaticAnalyzer/Checkers/MallocChecker.cpp:222
@@ -220,4 +221,3 @@
   mutable std::unique_ptr<BugType> BT_OffsetFree[CK_NumCheckKinds];
-  mutable IdentifierInfo *II_malloc, *II_free, *II_realloc, *II_calloc,
-                         *II_valloc, *II_reallocf, *II_strndup, *II_strdup,
-                         *II_kmalloc, *II_if_nameindex, *II_if_freenameindex;
+  mutable std::unique_ptr<BugType> BT_ZerroAllocation[CK_NumCheckKinds];
+  mutable IdentifierInfo *II_alloca, *II_alloca_builtin, *II_malloc, *II_free,
----------------
Quuxplusone wrote:
> This should presumably be "Zero", not "Zerro".
Thanks!

================
Comment at: test/Analysis/malloc-annotations.c:51
@@ -47,1 +50,3 @@
+  int *p = malloc(12);
+  realloc(p,0); // no-warning
 }
----------------
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.

http://reviews.llvm.org/D6178

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