How to fix leak on [NSString availableStringEncodings]? - ios

Question

When profiling the project, leaks were found and located to [NSString availableStringEncodings] in below function. No idea how to fix it :
- (NSString *)stringFromArchive:(NSString *)fileName inDirectory:(NSString *)folderName
{
NSString *rStr = #"";
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSString *folderPath = [documentsDirectory stringByAppendingPathComponent:folderName];
NSString *filePath = [folderPath stringByAppendingPathComponent:fileName];
NSFileManager * fileManager = [NSFileManager defaultManager];
if ([fileManager fileExistsAtPath:filePath]) {
NSError *error;
const NSStringEncoding *encodings = [NSString availableStringEncodings];
NSStringEncoding encoding1;
while ((encoding1 = *encodings++) != 0)
{
rStr = [NSString stringWithContentsOfFile:filePath encoding:encoding1 error:&error];
if (rStr == nil) {
NSLog(#"error: %#", error);
}else{
break;
}
}
}
return rStr;
}
enter image description here

Answer 1

As seen often and it is very common to find Object declarations without initial value but found out in hard learning curve that a lot of leaks I found where bound to the easy peasy practice of unitialised declarations...
in Short: proper declaration helps the debugger/instruments as well.
NSError *error;   very often seen. Can even leak, at least instruments finds it suspicious
NSError *error = nil;   better, and also not NULL (which leaks for sure).
NSStringEncoding encoding1;
is an ENUM of NSUInteger and you seem to try to iterate thru all encodings from the bottom up until you find a match that properly reads the file.. then you may want to start not with an undefined value but with 1 which is the most simple one (NSASCIIStringEncoding). Which is why you use break; and compare against !=0, so it iterates up to the end of the zero-terminated list (tells you also why the enum does not start with 0 but NSASCIIStringEncoding==1).
and also when you use const NSStringEncoding *var and then *var++ what is increased? The pointers address or the value that was stored at that address.., *(var++) vs (*var)++. Both could work fine but one is more risky the other iterates thru encodings that do not exist. So guessing you want to go thru the list of encodings up to its zero-termination, take the values and try reading...
NSString *rStr = #"";
NSError *error = nil;
const NSStringEncoding *a = [NSString availableStringEncodings];
NSStringEncoding b = NSASCIIStringEncoding;
// increase addr of a, take value to b
// and check for b not 0==end-of-list
while ( (b=*(a++))!=0 ) {
//iterate until encoding allows reading successful..
rStr = [NSString stringWithContentsOfFile:#"yourfile.." encoding:b error:&error];
if (rStr != nil) break; // rStr has content, so end loop
// print reason on any missed trial
NSLog(#"error: %#", error);
}
edit: made a leak on purpose just for fun if Instruments will detect it, the leaking code i used...
extern "C" int leakingCppFunction(const char * s)
{
Example *e = new Example(s); //e is never deleted, so it leaks.
return e->getLen();
}
clearly finds this leak and none in the encoding iteration discussed above. So guessing your extension (NSStringOtherEncodings) is causing availableStringEncodings to leak.