Re: Leaked NSString from class_getInstanceMethod

Kyle Sluder <[email protected]> Sat, 23 Jul 2011 10:19:04 -0700
Newsgroups gmane.comp.macosx.devel
Message-ID <CANEs-cyd7rFRhd4UJkhVOuJb7oQue4NnkVpwZNTNctEt9yM7tw@mail.gmail.com>
On Sat, Jul 23, 2011 at 10:14 AM, Christiaan Hofman <[email protected]> wr=
ote:
> I don't think the runtime (function, not method) should ever use any Coco=
a methods and objects, because the runtime is called before the Cocoa class=
es are properly setup and initialize. Calling any Cocoa from a runtime meth=
od will almost certainly lead to problems, because the whole setup of Cocoa=
 itself will be mixed up. So I disagree that there's no such guarantee. Qui=
te to the contrary, if such a guarantee would not exist, than logically the=
 whole runtime would be internally inconsistent and buggy by design. I cann=
ot believe that would be the case.
>

[ snip ]

> And I am using functions rather than Cocoa precisely because I know it's =
fragile. I do know very well that you simply cannot use Cocoa in +load, tha=
t's always dangerous, because +load can be called before Cocoa has been ful=
ly set up and initialized. So also using my own autorelease pool in +load i=
s dangerous, so I cannot even do what this comment suggests.
>
> What is also strange is that when I define a local autorelease pool, its =
-addObject: method is never called.

There's no guarantee that the runtime goes through the
NSAutoreleasePool facade to get at the underlying autorelease service.

--Kyle Sluder