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 <[email protected]> 写道： > 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 > _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
