[swift-dev] NSProxy dynamic casting to Swift or ObjC class behaves differently

[Yavuz Nuzumlalı]

Hi all,

swift_dynamicCastClassUnconditional
<https://github.com/apple/swift/blob/3d2b5bcc5350e1dea2ed8a0a95cd12ff5c760f24/stdlib/public/runtime/Casting.cpp#L508>
and
swift_dynamicCastObjCClassUnconditional
<https://github.com/apple/swift/blob/2daa1400cf79a2965eb07034b48ef7fae02459fd/stdlib/public/runtime/SwiftObject.mm#L1155>
methods
behave differently while verifying casting.

swift_dynamicCastObjCClassUnconditional
<https://github.com/apple/swift/blob/2daa1400cf79a2965eb07034b48ef7fae02459fd/stdlib/public/runtime/SwiftObject.mm#L1155>
method
calls *-isKindOfClass:* method before falling back to *object_getClass*
 function.

swift_dynamicCastClassUnconditional
<https://github.com/apple/swift/blob/3d2b5bcc5350e1dea2ed8a0a95cd12ff5c760f24/stdlib/public/runtime/Casting.cpp#L508>
method
calls *swift_dynamicCastClass* method which calls *_swift_getClassOfAllocated
<https://github.com/apple/swift/blob/82509cbd7451e72fb99d22556ad259ceb335cb1f/stdlib/public/runtime/Private.h#L80>*
method
which calls directly *object_getClass* function.

This causes problems if underlying object is an NSProxy subclass.

NSProxy class does not implement *-isKindOfClass:* method, so calls to this
method are forwarded to the real object through *-forwardInvocation:*
method, which causes *-isKindOfClass:* method to return answer according to
the real object's class.

However, *object_getClass* function directly accesses to the metadata of
the given object, so it returns NSProxy subclass.

I think this is a conflicting behavior, and I think
swift_dynamicCastClassUnconditional
<https://github.com/apple/swift/blob/3d2b5bcc5350e1dea2ed8a0a95cd12ff5c760f24/stdlib/public/runtime/Casting.cpp#L508>
method
should also verify first using *-isKindOfClass:* method, in order to
provide consistency.

What do you think?

Best
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160608/6fa472be/attachment.html>