Re: C++ pointer to Cocoa object
Re: C++ pointer to Cocoa object
- Subject: Re: C++ pointer to Cocoa object
- From: Greg Parker <email@hidden>
- Date: Fri, 07 Sep 2018 16:25:53 -0700
> On Sep 7, 2018, at 3:48 PM, Jens Alfke <email@hidden> wrote:
>
>> On Sep 7, 2018, at 10:46 AM, Casey McDermott <email@hidden> wrote:
>>
>> Problem is, with ARC turned on, the pointer is never nil, so it crashes.
>> The void pointer somehow becomes an NSAtom instead of 0.
>
> Something wrote to that pointer, then. If you initialize it to nullptr, it
> will stay that way. NSAtom is a red herring — probably the mCocoaPopupPtr was
> pointing to a valid object, but it got freed, and there is now (by chance) an
> NSAtom instance residing at that address.
NSAtom is one of the tagged pointer object classes. On 64-bit macOS, if you
have an address whose lowest four bits are 0x…1, and you use it as if it were
an Objective-C object, then it will be an NSAtom. (Same for 64-bit iOS, except
with an address that starts with 0x8….)
Nothing in the OS actually uses class NSAtom. (We're trying to get rid of it
but there are some binary compatibility problems.) Instead of "pointer variable
somehow becomes an NSAtom" you should be looking for "pointer variable somehow
has a random or uninitialized value". For example, if the object that contains
this mCocoaPopupPtr field were itself deallocated then a use-after-free could
cause this symptom.
>> Is there some other way to test for an invalid void pointer?
There is no way to programmatically distinguish all valid Objective-C object
pointers from all invalid ones. It's just like C and C++ in that respect.
--
Greg Parker email@hidden <mailto:email@hidden> Runtime
Wrangler
_______________________________________________
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