#autoreleasepool when extending NSData? - ios

Question

I'm working on a NSData extension that encrypts data with a key, as shown below. I'm not too savvy with Objective-C, but would like to use it for this Cordova plugin, instead of requiring another plugin to bridge Swift files.
I'm curious if I need to do any work to ensure that all clean-up in my methods is happening, so that each time this method is called, there are no leaks.
When extending an NS object, does one need to wrap their methods in #autoreleasepool {}?
This is the method that encrypts data (NSData+AES256Encrypt.m):
- (NSData *)AES256EncryptWithKey:(NSString *)key {
// 'key' should be 32 bytes for AES256, will be null-padded otherwise
char keyPtr[kCCKeySizeAES256 + 1]; // room for terminator (unused)
bzero(keyPtr, sizeof(keyPtr)); // fill with zeros for padding
// Get key data
[key getCString:keyPtr maxLength:sizeof(keyPtr) encoding:NSUTF8StringEncoding];
NSUInteger dataLength = [self length];
size_t bufferSize = dataLength + kCCBlockSizeAES128;
void *buffer = malloc(bufferSize);
size_t numBytesEncrypted = 0;
CCCryptorStatus cryptStatus = CCCrypt(kCCEncrypt, kCCAlgorithmAES128,
kCCOptionPKCS7Padding, keyPtr,
kCCKeySizeAES256, NULL, [self bytes],
dataLength, buffer, bufferSize, &numBytesEncrypted);
if(cryptStatus == kCCSuccess) {
return [NSData dataWithBytesNoCopy:buffer length:numBytesEncrypted];
}
free(buffer);
return nil;
}
It is used in conjunction with NSString+AES256Encrypt.m:
- (NSString *)AES256EncryptWithKey:(NSString *)key {
NSData *plainData = [self dataUsingEncoding:NSUTF8StringEncoding];
NSData *encryptedData = [plainData AES256EncryptWithKey:key];
NSString *encryptedString = [encryptedData base64Encoding];
return encryptedString;
}
The line that concerns me is free(buffer) used in the first method posted above, called if cryptStatus is false (meaning it failed to encrypt). I also notice that method dataWithBytesNoCopy has a parameter freeWhenDone which:
If YES, the returned object takes ownership of the bytes pointer and frees it on deallocation.
But I'm not sure if it applies to my situation.
Thanks for any and all help.

Answer 1

I don't see any issues.
Autoreleasing is only for Objective-C objects. It basically delays the actual -release call a little bit by putting the object in an autorelease pool, which gets flushed after every iteration of the main run loop, calling -release on every object in the pool. Objects returned from methods are typically autoreleased, though ARC has a mechanism which can often avoid the overhead of the actual pool by figuring out that the value is only needed by the caller, and can keep track of the reference and just call -release there. In ARC mode, the compiler figures out for you when autorelease vs release is needed, and does not let you call those methods yourself.
Most of the time, you don't need your own autorelease pools, though if you are doing something in a loop where every iteration can create lots of temporary objects, you may want an autorelease_pool for every loop iteration so that memory does not get built up but rather gets cleaned up each time so the next iteration can re-use that memory. If you are writing a command-line program or some other tool which does not have its own Objective-C support, then yes you need an autorelease pool around the entry point at least.
C heap memory using malloc/free is outside the autorelease concept (which only pertains to the retain/release mechanism of NSObject). For every malloc(), you need to eventually call free() on that memory once it is no longer needed, otherwise it's a leak. The code above is correct -- there is a malloc(), and then either free() is called when returning nil, or the initWithBytesNoCopy: method is called (which is a special method which uses the passed-in bytes as the actual NSData storage, avoiding the overhead of a memory copy and further internal malloc, and will then call free() when the object itself is dealloced).
initWithBytesNoCopy:length: just calls -initWithBytesNoCopy:length:freeWhenDone: with a YES parameter for freeWhenDone, basically, per its documentation. You can call the longer method explicitly if you think it makes it more readable (as it does more clearly indicate you were aware of the free behavior), but it will work the same either way.
The NSData encrypt method really doesn't create any objects other than the one you are returning -- all of its code is more straight C code. So an autorelease pool would not help anything. The NSString encrypt method does create a few temporary objects, so if the amount of memory being encrypted is substantial, an autorelease pool around that may help if you have subsequent significant work (but be sure to have a strong reference to the object being returned outside the pool scope). And really, ARC will most likely figure out the temporary nature of most of those objects, and more efficiently deal with them than an autorelease pool anyways.
If you can profile your code using Instruments, you can see the memory usage of your program as it runs, and it would only be places with significant spikes that you would consider using a local autorelease pool.