|
|
|
|
|
by mikeash
4746 days ago
|
|
There's no unpredictability. CFMakeCollectable does nothing when not using garbage collection. That's explicitly documented. Without GC, this code would have been written as simply: CFRetain(data);
And the same bug would manifest. The bug is just a missing release call.Edit: I'd assume they were going for the standard pattern for code that needs to be both GC and non-GC for bridging CF objects out into the Cocoa world: [NSMakeCollectable(cfobj) autorelease];
In this case, "obj" was retained inline. They just forgot the autorelease. They could have forgotten it just as easily without garbage collection, and the NSMakeCollectable (which inlines to CFMakeCollectable) call is unrelated, aside from possibly occupying the wrong spot of the original programmer's brain at the wrong moment. |
|
However, imo the intention and semantics behind a call like CFMakeCollectable implies a transfer of ownership to an external system. A newbie Apple coder could be forgiven for thinking it would still transfer ownership in RC environments, just to the autorelease pool instead of a collector. In all likelihood this is what happened. An intern got at the code and didn't know the details about GC.
Obviously the point stands that this interpretation is well-documented to be false, but its naming is definitely misleading.
Double edit: I see from your edit that some of my basic assumptions about CFMakeCollectable were wrong, having never actually worked with it. My bad.