r178388 - [analyzer] Enabled unix.Malloc checker.
Anton Yartsev
anton.yartsev at gmail.com
Fri Mar 29 18:35:33 PDT 2013
On 30.03.2013 4:59, Jordan Rose wrote:
>
> On Mar 29, 2013, at 17:50 , Anton Yartsev <anton.yartsev at gmail.com
> <mailto:anton.yartsev at gmail.com>> wrote:
>
>> +//----- Test free standard new
>> +void testFreeOpNew() {
>> + void *p = operator new(0);
>> + free(p);
>> +} // expected-warning{{Memory is never released; potential leak}}
>> +// FIXME: Pointer should escape
>> +
>> +void testFreeNewExpr() {
>> + int *p = new int;
>> + free(p);
>> +} // expected-warning{{Memory is never released; potential leak}}
>> +// FIXME: Pointer should escape
>> +
>> +void testObjcFreeNewed() {
>> + int *p = new int;
>> + NSData *nsdata = [NSData dataWithBytesNoCopy:p length:sizeof(int)
>> freeWhenDone:1]; // expected-warning{{Memory is never released;
>> potential leak}}
>> +}
>> +// FIXME: Pointer should escape
>
> These don't escape because we assume arbitrary system functions don't
> free memory. I think these are fine when unix.Malloc is disabled.
Now, when allocation families got in, I would like to propose to split
doesNotFreeMemOrInteresting() into two: doesNotFreeMem() and
isInteresting() or something similar.
doesNotFreeMem() should return "true" for a given call if it is known
not to free memory, and "false" otherwise.
For a known deallocation function isInteresting() should return "true",
if a deallocation function is of the same family, as allocation one, and
"false" otherwise. It also may contain any additional logic for
non-deallocation functions if required.
With this logic the cases will be considered as pointer escape that is
symmetrical to the reverse case, when malloced memory is deleted (assume
NewDelete id ON and UnixMalloc is OFF):
void testDeleteMalloced() {
int *p = (int *)malloc(sizeof(int)); // do not add RefState to p
delete p; // keep silent
}
One more argument: that cases should be the subject of
unix.MismatchedDeallocator - the memory /is/ deallocated, but the
deallocator do not match the allocator.
What do you think?
--
Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130330/3bed97f2/attachment.html>
More information about the cfe-commits
mailing list