[cfe-dev] [Patch] Generate a warning if a message is sent to a nil receiver with return type larger than void* (PR 2718)

[Nikita Zhuk]

On 8.4.2009, at 20.48, Ted Kremenek wrote:

> Hi Nikita,
>
> I see; [obj intM] should evaluate to 0 if obj is nil.  Sure that  
> would be easy to do!

Great!

> Incidentally, this example touches on same dangerous territory as  
> far as reasoning about sending messages to nil, as some of these  
> semantics are architecture specific and could change with the whim  
> of any updates to the runtime.
> As you know, for portability the only thing we can assume is (from  
> the referenced doc):
>
> "The Objective-C runtime assumes that the return value of a message  
> sent to a nil object is nil, as long as the message returns an  
> object or any integer scalar of size less than or equal to  
> sizeof(void*)."
>
> While this seems pretty clear for 'int', pointers, etc., long long  
> doesn't fall into that category.  In fact that's only kosher on  
> Intel macs, and the documentation even says that is undefined for  
> PowerPC.  I'm also not certain what the results would be for ARM,  
> but I imagine that the result would be undefined as well.  This  
> means this code will break when used to build an iPhone app.

Yes, that's why I used the "[obj intM]" method in those examples  
(underlying assumption being that the "intM" method returns 'int',  
which is a safe return type for messages being sent to nil). If  
condition of an 'if' statement would have been "if([obj longlongM] !=  
0)", then static analyzer should issue the nil receiver warning and  
not to assume anything about the value of the condition (as it does  
now).

I have a feeling (based on communication with other developers, no  
hard data to back it up) that this particular issue is not very well- 
known in Obj-C developer community, so getting this check into Clang  
is a very good thing (of course, static analysis is not enough to find  
all possible cases of incorrect use of the nil receiver, but it's a  
start).

> I think there are two strategies we can take here.  We either issue  
> target-specific warnings or target-independent warnings.  Target- 
> independent warnings would flag cases that are potentially non- 
> portable.  I realize that you weren't arguing that the analyzer  
> specially handle the [ob longlongM] case, but I thought I would  
> bring these issues up while we are here.
>
> Ted

I would personally vote for target-independent warnings and portable  
code, but there're certainly developers with different requirements.