gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreBase toll-free bridging


From: Maxthon Chan
Subject: Re: CoreBase toll-free bridging
Date: Wed, 27 Mar 2013 09:03:13 +0800

Based on your research, I am seriously doubting what is actually inside the 
CoreFoundation binary: is it possible that actually all Objective-C code that 
involves toll-free bridging or like, or maybe even more, that is documented as 
located in Foundation, is actually located right in CoreFoundation, and 
Foundation binary is simply (re)exporting symbols for them? Or did Apple made 
extensive use of Objective-C runtime to dynamically bind Core Foundation 
functions to Foundation classes? (which is highly unlikely.)

在 2013-3-27,上午4:01,Luboš Doležel <address@hidden> 写道:

> Hi again,
> 
> I was investigating what approach Apple took in solving a problem with 
> calling CF functions on ObjC objects, which return an autoreleased object in 
> ObjC, but clearly shouldn't do so when using the CF call.
> 
> For instance, you have to release the result of CFTimeZoneCopyLocalizedName() 
> yourself, but you mustn't do that with [NSTimeZone localizedName:locale:], 
> since that will be autoreleased.
> 
> An ordinary CF_OBJC_FUNCDISPATCH from the former to the latter therefore 
> doesn't work correctly "out of box". Apple's source code showed no solution 
> at all, but still on OS X it seemed to work correctly...
> 
> So I took my disassembler again and voilá! The source code released by Apple 
> under the 10.8 section *doesn't match* the OS X 10.8 binares. In CFTimeZone's 
> case it doesn't match it at all.
> 
> CFTimeZone on OS X is *entirely* built on top of NSTimeZone.
> 
> CFTimeZoneCopyLocalizedName() actually does something like this:
> 
> =====
> _CFAutoreleasePoolPush();
> NSString* retval = [(NSTimeZone*)tzSelf localizedName: arg1
>                                               locale: arg2];
> 
> CFRetain(retval);
> _CFAutoreleasePoolPop();
> 
> return retval;
> =====
> 
> Which explains why it doesn't exhibit the above described problem as one 
> would expect from their source code.
> 
> So Chan, you were partially right. But I've checked other types and it seems 
> it is the case only in CFTimeZone.
> 
> -- 
> Luboš Doležel
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]