[cfe-dev] Comparison of pointers between Objc subclasses
Jean-Daniel Dupas
devlists at shadowlab.org
Wed Jul 2 07:28:20 PDT 2008
Le 2 juil. 08 à 16:05, David Chisnall a écrit :
> On 2 Jul 2008, at 14:16, Jean-Daniel Dupas wrote:
>
>>
>> Le 2 juil. 08 à 12:58, David Chisnall a écrit :
>>
>>> On 2 Jul 2008, at 00:22, Ted Kremenek wrote:
>>>
>>>> Are pointer type compatibility checks for assignments and
>>>> conversions
>>>> being handled in the same way? I can understand why assigning a
>>>> base
>>>> type to a derived type is dangerous, but it seems to me that
>>>> comparisons like these should be legal. I'm only raising this
>>>> point
>>>> because the code snippet with the warning involved a comparison,
>>>> not
>>>> an assignment.
>>>
>>> Comparisons between ObjC pointers should contain an implicit cast to
>>> id. I tweaked CodeGen to do this and sent the patch a month or so
>>> ago, but it wasn't an ideal solution since the problem is really in
>>> Sema, and it only fixed a few cases where Sema was doing almost the
>>> right thing but omitting the implicit cast.
>>
>> Wouldn't this implicit cast prevent the "comparison of distinct
>> Objective-C types lacks a cast" warning ?
>
> No. The warning is just a warning. Objective-C type tags are
> informative, nothing more. The type of an Objective-C object is a
> property of the object, not of the variable holding the object. The
> warning says 'you think these two objects have different types, but
> you are still comparing them, are you sure that's sensible?' The
> implicit cast should be inserted so that CodeGen will generate the
> correct code, rather than failing because you are comparing distinct
> pointer types.
>
> The same is true of an assignment. It is perfectly legal to assign
> any object pointer to any other object pointer in Objective-C, it
> just isn't usually sensible, which is why you get a warning. In
> some situations, however, it is useful. You might have something
> like this:
>
> - (void) method:(A*)anObject
> {
> if ([anObject isKindOfClass:[B class]])
> {
> [self methodExpectingB:(B*)anObject];
> }
> else
> ...
> }
>
> This can be required because Objective-C objects have two types -
> the implicit type determined by their signature and their structural
> type. The tag type carries both implicitly. You can safely pass
> object B to something expecting A if it implements every method of
> A. You may also want to override a method which expects an A, and
> have a special case for objects of type B, which either accesses
> their instance variables directly, or uses some methods only present
> in B. Of course, this is better done with protocols, but that
> requires you to have access to the class which you are subclassing's
> source code.
>
> David
Sorry, didn't notice it was about implicit cast into CodeGen (and so
should not have any impact on parse and Sema, and so on warning).
Of course, I fully agree with you. The Obj-C runtime don't care about
what kind of object you pass, as long as it's first field is an isa
pointer (at least for the Apple runtime) and it can dynamically
dispatch method on it (even if the object does not directly handle the
message and uses forwarding or dynamic method generation to handle it).
-------------- 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/20080702/b78e537a/attachment.bin>
More information about the cfe-dev
mailing list