Re: WTF is happening?
Re: WTF is happening?
- Subject: Re: WTF is happening?
- From: Jean-Daniel Dupas <email@hidden>
- Date: Sun, 14 Dec 2014 01:17:52 +0100
The Object class is not used anywhere is OS X. It is deprecated and should have been removed from the runtime long time ago.
The OS X kernel does not even include obj runtime, so it can’t possibly use the Object class. Mach port are integer that represent kernel object and not classes.
The root class for all OS Object (XPC, GCD, …) is NSObject (which live in the runtime too).
If you find subclasses of Object, you are obviously doing something wrong.
> Le 13 déc. 2014 à 20:57, Maxthon Chan <email@hidden> a écrit :
>
> 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) 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@hidden> 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@hidden> 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@hidden> 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@hidden> 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@hidden> 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@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden