[cfe-dev] Missing dealloc analysis

Jean-Daniel Dupas devlists at shadowlab.org
Thu Jul 3 10:18:49 PDT 2008


Le 3 juil. 08 à 18:28, Ted Kremenek a écrit :

> Hi Nikita,
>
> On Jul 2, 2008, at 10:35 PM, Nikita Zhuk wrote:
>
>> I noticed the addition of missing dealloc analysis in r53075. It's a
>> good idea to check that dealloc is implemented and that it always
>> calls [super dealloc], but there're couple of points I would like to
>> mention:
>>
>> 1. It should be disabled in GC environment, because dealloc methods
>> are not called under GC
>
> Done:
>
>   http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006371.html
>
>> 2. In non-GC environment, the primary function of dealloc method is  
>> to
>> update retain counts of variables the object being dealloced is
>> pointing to. So that usually means that dealloc must be implemented
>> when an object has some ivars. Dealloc is not always required, and
>> there're lot of classes which don't need it (e.g. singleton classes).
>> Currently missing dealloc analysis requires every class to implement
>> dealloc and it's causing a lot of false positives.
>>
>> I'm not completely sure if absence of ivars should be the only factor
>> which disables missing dealloc analysis, but at least in my case it
>> would suppress a lot of false positives.
>
> Done:
>
>   http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006373.html
>
> Both commits are now rolled into checker-55 on the Clang website.
>
> These are both great suggestions.  I remembered the GC/non-GC issue
> this morning before I read your email, and I can easily see how not
> checking to see if a class contains any ivars would lead to many false
> positives.  I also believe that checking for ivars should also handle
> the Singleton design pattern (please correct me if I am wrong).

Why do you think singleton class need a special case ?

in obj-c a singleton class is usually implemented using a class method  
that return a shared instance:

+ (id)sharedInstance {
	static Foo *sharedInstance = nil;
	if (!sharedInstance) {
		sharedInstance = [[Foo alloc] init];
	}
	return sharedInstance;
}

optionaly you can also override +alloc, -init, -retain, -release to  
prevent creation of other instance, and destruction of the shared  
instance, but this is not recommanded (except if you have a good  
reason to do so).

It's a good practice to release ivars in a singleton dealloc, even if  
dealloc may never be call (like that, if needed, you can create other  
instance of this class).

So I don't think it need a special case, but I maybe wrong too.


> Please keep these great comments/suggestions coming!  The goal is to
> have most checks have a false positive rate to not exceed 20%, and
> incorporating simple heuristics like these is often a huge win in
> cutting down false positives.
>
> Ted
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2427 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080703/7311cb01/attachment.bin>


More information about the cfe-dev mailing list