[cfe-dev] Objective-C really strong type checking

[Marcin Świderski]

2010/9/8 Fariborz Jahanian <fjahanian at apple.com>

>
> On Sep 8, 2010, at 11:05 AM, Ted Kremenek wrote:
>
>  On Sep 8, 2010, at 2:01 AM, Marcin Świderski wrote:
>>
>>  Hi All
>>>
>>> Is there a check implemented in Clang Checker (maybe not released for
>>> XCode yet) that would find errors like in example:
>>>
>>> @interface SomeClass : NSObject {
>>>  NSMutableDictionary *_someObjects;
>>> }
>>> @end
>>>
>>> @implementation SomeClass
>>> - (id)init {
>>>  if ((self = [super init])) {
>>>   _someObject = [NSMutableArray new];
>>>  }
>>>  return self;
>>> }
>>> @end
>>>
>>> Methods 'new' or 'init' return object of type 'id' by convention, but as
>>> I experienced it myself it can be unsafe.
>>>
>>> Cheers
>>> Marcin
>>>
>>
>> This isn't implemented, but it would be a great check and would be really
>> easy to do.
>>
> Problem with this is that this is very common form of assignments in objc
> and checker will get very noisy.
>
> - Fariborz
>
> Maybe you missed the point: there's NSMutableArray object assigned to
attribute of NSMutableDictionary type, and those types have completly
different interfaces. If the programmer would realy want this, he could use
attribute of type 'id' and live with possibility of runtime errors.

Possibility for false positives is when we have case in which some class in
method new returns object of it's subclass (or maybe completly different
class) and the caller uses the true type of returned object. This is however
error in code that should be caught, because the caller should not use the
true type as it defeats the whole purpose of such abstraction. However the
check could honor explicit cast for such cases, as we can assume that the
programmer have been warned and knows what he's doing from now on.

As for implementing this check I'm not interested, because I have some C++
checks to do for my thesis right now. However I'm always interested in
using/testing checks that provide some more type checking for Objective-C :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100908/8613c196/attachment.html>