Re: Static analyser less rigorous nowadays?
Re: Static analyser less rigorous nowadays?
- Subject: Re: Static analyser less rigorous nowadays?
- From: Martin Wierschin <email@hidden>
- Date: Mon, 12 Dec 2011 17:43:36 -0800
It does seem like the static analyzer should have given you warnings for that mess. It certainly would be best if it did!
I just ran into a situation myself where the analyzer failed to catch a leak:
#define XXX_ASSERT(_expression_) \ if (!(_expression_)) \ (void)0;
- (id) whateverArray { NSMutableArray* mutableArray = [[NSMutableArray alloc] initWithCapacity:100]; NSArray* result = [mutableArray copy];
[mutableArray enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL* stopPtr){ XXX_ASSERT( [mutableArray isKindOfClass:nil] ); XXX_ASSERT( [result isKindOfClass:nil] ); }];
[mutableArray release]; return result; }
That's the minimal/gutted version of the code that fails to trigger a warning about not (auto)releasing the return value. The block and assert macros are required to trigger the issue.
I'm still using Xcode 3.2.6 for this project, and I don't keep tabs on clang. Does anyone know, do I bother to report analyzer bugs even in non-current versions of Xcode?
~Martin
On 2011.12.09, at 3:57 AM, steven hooley wrote: Is my memory playing tricks or would the following once have produced a complaint or at least a whinge from Clang?
- (void)foo:(NSString *)bar { [bar release]; [bar release]; [bar release]; [bar release]; id boo = bar; [boo release]; [boo release]; [boo release]; [boo release]; }
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden