> On Sep 7, 2018, at 3:48 PM, Jens Alfke <j...@mooseyard.com> wrote: > >> On Sep 7, 2018, at 10:46 AM, Casey McDermott <supp...@turtlesoft.com> 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 gpar...@apple.com <mailto: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
