================ 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/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
