I found only 5 classes that does not responds to isProxy and they are all internal classes, so real code will never have to deal with instances of such classes.
And all classes prefixed by « OS_ » inherits NSObject and responds to isProxy. I run the experiment for myself and do not doubt the result. > Le 15 déc. 2014 à 12:12, Charles Jenkins <[email protected]> a écrit : > > During the course of this thread, Maxthon has given us code that would enable > us to run the experiment for ourselves. I do not doubt him. > > — > > Charles Jenkins > > > On Monday, December 15, 2014 at 2:31 AM, Maxthon Chan wrote: > >> My class scanning returned several OS* classes that does not conform to >> NSObject protocol. >> >>> On Dec 15, 2014, at 00:29, Clark S. Cox III <[email protected] >>> (mailto:[email protected])> wrote: >>> >>>> >>>> On Dec 13, 2014, at 11:57, Maxthon Chan <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> NSProxy checking actually work, but throwing those classes that derive >>>> from Object class (note I used capitalised O here, the old Object class >>>> from early NeXT times, also used heavily in OS X kernel, GCD and Mach >>>> ports) >>> >>> What makes you think that Object is used in *any* of those places? >>> >>>> into the mix means that no method can be sent before class is determined. >>>> I would suggest Apple add one runtime function class_isSubclassOfClass() >>>> that mirrors the functionality of NSObject and NSProxy method >>>> isSubclassOfClass so that derivatives of the old Object class can be >>>> detected more easily. >>>> >>>>> On Dec 14, 2014, at 03:49, Gary L. Wade <[email protected] >>>>> (mailto:[email protected])> wrote: >>>>> >>>>> Are you saying that Apple's well-documented approach to see if an object >>>>> is derived from NSProxy does not work? If that's the case, you need to >>>>> submit a bug report to Apple. That's a serious issue that only Apple can >>>>> help you with. >>>>> >>>>> If you are using objects not derived from NSObject nor NSProxy, then >>>>> change your design. >>>>> -- >>>>> Gary L. Wade (Sent from my iPad) >>>>> http://www.garywade.com/ >>>>> >>>>>> On Dec 13, 2014, at 11:40 AM, Maxthon Chan <[email protected] >>>>>> (mailto:[email protected])> wrote: >>>>>> >>>>>> Ain’t work! Will crash if an Object derivative showed up. >>>>>> >>>>>> I am scanning ALL loaded classes and only subclasses of a certain class >>>>>> is interested. But due to the nature of this class scanning before I can >>>>>> make sure that the class derives from NSObject I cannot call any method >>>>>> on it. >>>>>> >>>>>>> On Dec 14, 2014, at 03:34, Gary L. Wade <[email protected] >>>>>>> (mailto:[email protected])> wrote: >>>>>>> >>>>>>> If all you care about is if an object is a proxy or not, look at >>>>>>> isProxy. >>>>>>> -- >>>>>>> Gary L. Wade (Sent from my iPad) >>>>>>> http://www.garywade.com/ >>>>>>> >>>>>>>> On Dec 13, 2014, at 11:06 AM, Maxthon Chan <[email protected] >>>>>>>> (mailto:[email protected])> wrote: >>>>>>>> >>>>>>>> What I am doing here is scanning all loaded classes for subclasses of >>>>>>>> a certain class. Before any NSObject method can be issued I have to >>>>>>>> check if it is actually NSObject or NSProxy derivative instead of an >>>>>>>> Object derivative that does not support NSObject methods. This calls >>>>>>>> for runtime equivalent for one of the following NSObject methods: >>>>>>>> >>>>>>>> - [NSObject respondsToSelector:(SEL)aSelector] = >>>>>>>> class_respondsToSelector(Class, SEL) // this crashed. >>>>>>>> + [NSObject conformsToProtocol:(Protocol *)aProtocol] = >>>>>>>> class_conformsToProtocol(Class, Protocol *) // check for NSObject >>>>>>>> protocol, this does not work. >>>>>>>> + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to >>>>>>>> implement it myself >>>>>>>> >>>>>>>> I ended up creating this: >>>>>>>> >>>>>>>> BOOL class_isSubclassOfClass(Class cls, Class other) >>>>>>>> { >>>>>>>> for (Class c = cls; c; c = class_getSuperclass(c)) >>>>>>>> if (c == other) >>>>>>>> return YES; >>>>>>>> return NO; >>>>>>>> } >>>>>>>> >>>>>>>> If i remembered it right GNUstep runtime have this function. I will >>>>>>>> file a bug report to Apple and ask them to add this, as it is useful >>>>>>>> in class scanning and i am using this technique heavily in jailbreak >>>>>>>> detection. >>>>>>>> >>>>>>>>> On Dec 14, 2014, at 01:20, Kyle Sluder <[email protected] >>>>>>>>> (mailto:[email protected])> wrote: >>>>>>>>> >>>>>>>>> On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote: >>>>>>>>>> Why do you think the problem is with “respondsToSelector:”? The error >>>>>>>>>> says you’re accessing past the end of a string. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Because the crash happens in a call stack that originates in >>>>>>>>> class_respondsToSelector, and involves none of Maxthon's code. >>>>>>>>> >>>>>>>>> --Kyle Sluder >>>> >>>> _______________________________________________ >>>> >>>> Cocoa-dev mailing list ([email protected] >>>> <mailto:[email protected]>) >>>> >>>> Please do not post admin requests or moderator comments to the list. >>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>>> <http://lists.apple.com/> >>>> >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com >>>> <https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com> >>>> >>>> This email sent to [email protected] <mailto:[email protected]> >> _______________________________________________ >> >> Cocoa-dev mailing list ([email protected] >> (mailto:[email protected])) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> (http://lists.apple.com) >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/cejwork%40gmail.com >> >> This email sent to [email protected] (mailto:[email protected]) >> >> >> Attachments: >> - smime.p7s >> > > > _______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > 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/mailing%40xenonium.com > > This email sent to [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
