4

I'm using a library that is not ARC compliant from an ARC based project. A function in that library returns a retained UIImage * object. Is there a way to use the __bridge attributes to let ARC know about this so it can manage the retain count of the returned object? I tried:

UIImage *returnedImage;
returnedImage = (__bridge_transfer UIImage *)functionThatReturnsAUIImage();

But it won't allow me to cast the UIImage * to a UIImage *). I also tried:

returnedImage = (UIImage *)(__bridge_transfer void *)functionThatReturnsAUIImage();

Which also didn't work. The compiler suggested __bridge_retained instead of __bridge_transfer, but that I believe would have done the opposite of what I was after (i.e. it would have increased the retain count on the returned UIImage object).

I believe the proper thing to do is to make the C function return an autoreleased object. As best as I can tell, ARC assumes any C function that returns an object will have returned an autoreleased object. I have access to the source for this library, so I can do this, but I was wondering if there was a solution I could employ from the calling side if I wasn't able to modify the library.

Brad Larson
  • 170,088
  • 45
  • 397
  • 571
neils4fun
  • 199
  • 1
  • 10
  • 2
    You can disable ARC for certain files instead of trying to make them ARC-compatible. See http://stackoverflow.com/questions/10184307/batch-adding-fno-objc-arc-flag-to-multiple-source-files/10184313#10184313. – Evan Mulawski Jun 19 '12 at 16:21
  • @EvanMulawski is right. Don't bother trying to make libraries ARC-compliant, there's no need at all. – Ben Clayton Jun 19 '12 at 16:30
  • Thank you both. I'm not trying to make the library arc compliant, it is not, and I'm fine with that. My issue is that the library has a C function in it (not an objc method) which returns a UIImage. My calling module, which IS arc compliant, calls this function and gets the UIImage back. What I believe happens then is ARC assumes that the c function is returning an auto-released instance of that UIImage, so it doesn't release it, and the UIImage leaks. – neils4fun Jun 20 '12 at 14:24
  • I think the intuition of making your code that's invoking this C function non-ARC is going down the right road (because you can then do your own manual memory management, such as invoking the necessary `release` or `autorelease`). If that's a bridge too far (sorry, couldn't help myself there), you could write your own image release function (see my answer below), which you could invoke from your ARC code, that way you get the best of both worlds, your code is predominantly ARC, but you have a single helper function to do the necessary release and get your retain count where it needs to be. – Rob Jun 23 '12 at 02:33

2 Answers2

3

It's too bad that the logical bridge modifier isn't working for you.

Two possible approaches leap out at me.

First, while it's not elegant, you could just write your own image release function, for example:

//  ImageManualMemoryManagement.h

#import <UIKit/UIKit.h>

int releaseImage(UIImage *img);

and

//  ImageManualMemoryManagement.m

#import "ImageManualMemoryManagement.h"

int releaseImage(UIImage *img)
{
    [img release];

    return 0;
}

In your project's target settings, under Build Phases, double click on this one .m source file under "Compile Sources" and add the non-ARC flag, -fno-objc-arc (to allow you to use the release method).

You now have a function you can call that will reduce the retain count of your UIImage and then all is good in the world again.

Second, the more dramatic solution would be to write your own non-ARC wrapper class around the entire C interface that your image library presents, remedying those few methods that aren't returning items with the correct retain count. But it seems like a lot of work for just one retainCount transgression. But if the library has it's own weaknesses (e.g. you're dealing with a clumsy low-level library), you might kill two birds with one stone.

Rob
  • 415,655
  • 72
  • 787
  • 1,044
2

According to apple's Transitioning to ARC Release Notes, __unsafe_unretained should be used here.

__unsafe_unretained specifies a reference that does not keep the referenced object alive and is not set to nil when there are no strong references to the object. If the object it references is deallocated, the pointer is left dangling.

Because ARC and MRC (manual reference counting) has different memory management rules, no keyword that has memory management influence works. The only choice is the keyword __unsafe_unretained which has no memory management influence to both ARC and MRC.

Daniel.W
  • 180
  • 1
  • 8