> On Dec 13, 2014, at 7:20 AM, Maxthon Chan <m...@maxchan.info> wrote: > > This got me scratching my head, hard. Why would class_respondsToSelector() > crash? (BTW this is used in a class search loop so I cannot use [NSObject > respondsToSelector:] just yet.)
Your evil runtime hack is colliding with someone else's evil runtime hack. If a class does not have an implementation for some selector then the runtime asks the class if it would like to add one using +resolveInstanceMethod: or +resolveClassMethod:. In this case you have found that the implementation of +[_NSObjectAnimator resolveInstanceMethod:] crashes. (It turns out that _NSObjectAnimator assumes the message is only sent to its subclasses, not to _NSObjectAnimator itself.) In general it is not safe to look up arbitrary classes and then send messages to them. Checking for conformance (using the C function, not the NSObject method) to a protocol you defined and then only sending messages from that protocol is the safest way to go. Filtering out classes with base classes that are not NSObject sometimes works. Filtering out classes whose names start with "_" sometimes works. -- Greg Parker gpar...@apple.com Runtime Wrangler _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
