[cfe-commits] [PATCH 1/1] Checking zero byte allocation for realloc() and calloc().
kremenek at apple.com
Sat Nov 26 22:26:36 PST 2011
On Nov 26, 2011, at 8:26 PM, Cyril Roelandt wrote:
> On 11/19/2011 05:35 AM, Jordy Rose wrote:
>> I didn't look into the patch in detail, but it's worth noting that realloc can be safe with a 0 size on BSD, at least. ("If size is zero and ptr is not NULL, a new, minimum sized object is allocated and the original object is freed." but "If ptr is NULL, realloc() is identical to a call to malloc() for size bytes.")
>> Also, how much overlap is there with MallocChecker? There's a fixme on CheckMallocZero already about having malloc-related checks in two places.
> So, here is a new version of the patch :
> * Remove all the malloc-related code from the UnixAPIChecker
> * Remove the malloc-related tests from test/Analysis/unix-fns.c
> * Check zero byte allocations for the malloc(), calloc() and realloc() functions in the MallocChecker
> * Add tests in test/Analysis/malloc.c
> About the realloc function, the C99 standard specifies that "if ptr is a null pointer, the realloc function behaves like the malloc function for the specified size". I am not sure anything is specified if the ptr is not NULL and the size is 0. With this patch, realloc(ptr, 0) will not raise any warning if ptr is not NULL.
I hate to give you confusing advice, but I think this should go into the UnixAPIChecker for now. I'm very sorry I didn't have time to review your original patch when you submitted it.
Jordy is absolutely right that putting this exclusively into MallocChecker is the right long term direction, but I disagree with him that this is what we should do right now. My concern is that the MallocChecker is not on by default, so moving this functionality from UnixAPIChecker to MallocChecker is actually a regression in functionality for most users.
The reason the MallocChecker is not on by default is because it makes very optimistic assumptions about wrapper functions for free() and malloc(). Basically, if it sees a pointer returned from malloc() passed to another function, it doesn't assume that the function frees that memory unless it is (a) free() or (b) is a function specially annotated with an attribute indicating that it is a free function. While this approach has merit, it will not really fly on most code out of the box, and will cause the checker to produce a bunch of noise (making it not eligible to be turned on by default yet). Unfortunately, this checker is likely one of those that we will need interprocedural analysis in order to work well in practice, or we have an option where we can relax the checker so it conservatively assumes that any function it doesn't understand *may* free its argument (although that would likely make the checker useless in practice).
I'm very sorry for not responding to your earlier patch. I know you submitted it weeks ago, and I've been massively backlogged on patch review.
Here's what I think we should do. I think we should put this checking logic into both UnixAPIChecker and MallocChecker. When MallocChecker is enabled by default, we remove this logic from UnixAPIChecker. We could possibly enhance UnixAPIChecker to check if the MallocChecker is enabled, and if so, not warn about these cases (avoiding duplicate checking).
Cyril/Jordy: what do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits