>> NSAtom is a red herring
Quite possible.
Usually we create the C++ object, which constructs a linker in the next line or
two.
Then that creates the Cocoa object in the next line or two and hooks them up.
They all stick around until all are deleted. Not much chance for object
lifetime prob
I ran into this while writing wrappers for pjsip in C++ to Obj-C and vice versa.
The only conclusion that I came to was to store what the valid pointer value
was after it was created. The failure cases could be an undefined or out of
range pointer but they proved not easily able to test for. A
> On Sep 7, 2018, at 3:48 PM, Jens Alfke wrote:
>
>> On Sep 7, 2018, at 10:46 AM, Casey McDermott 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 y
> On Sep 7, 2018, at 10:46 AM, Casey McDermott 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
Usually the way you get an NSAtom is because you’re reading garbage–either
somebody scribbled over your pointer or it was garbage to begin with. Does
mCocoaPopupPtr ever get set to nil? Does it have a consistent value? What
happens if you run with the Address Sanitizer enabled, or with NSZombieE
On Mon, 3 Sep 2018 15:31:37 +0200, Andreas Falkenhahn said:
>Optimally, I'm looking for a solution to flush the app bundle cache on
>the iMac from the makefile that I run on the Mac Mini I use for building.
Not sure what "the app bundle cache" is, but maybe nuking the LaunchServices db
would hel
On 9/7/18 10:46 AM, Casey McDermott wrote:
We need to link some of our C++ classes to a matching Cocoa class.
It's easy for Cocoa to reference C++ objects. Going the other way is harder.
We have been using a linker class that has a void pointer to the Obj-C object
in the C++ header. We then ca
You might also find WWDC 2018, Session 409, informative.
--
Gary L. Wade
http://www.garywade.com/
> On Sep 7, 2018, at 1:44 PM, Allan Odgaard wrote:
>
>> On 7 Sep 2018, at 19:46, Casey McDermott wrote:
>>
>> Problem is, with ARC turned on, the pointer is never nil, so it crashes.
>> The void po
On 7 Sep 2018, at 19:46, Casey McDermott 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.
Nil is nil, I think your issue is rather that you do not properly retain
the pointer before storing it as void*.
We need to link some of our C++ classes to a matching Cocoa class.
It's easy for Cocoa to reference C++ objects. Going the other way is harder.
We have been using a linker class that has a void pointer to the Obj-C object
in the C++ header. We then cast it to a Cocoa object in the Obj-C++ source
So I worked out most of this for myself.
My privileged helper tool is only executable by root. If I set it to
world-executable, then it's possible to drag and drop it into the Full Disk
Access panel. Still can't get it to show up when pressing the add/plus (+)
button, but that's not a big iss
11 matches
Mail list logo
