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

[Arthur O'Dwyer]

================
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,
----------------
This should presumably be "Zero", not "Zerro".

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

http://reviews.llvm.org/D6178

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