Re: Strange Static Analyzer Warning

On Dec 11, 2013, at 9:48 AM, Ken Thomases wrote: > On Dec 11, 2013, at 10:25 AM, Keary Suska wrote: > >> In this method: >> >> - (void) drawBezelWithFrame:(NSRect)frame inView:(NSView *)controlView { >> if (self.state == NSOnState) { >>// If selected we need to draw the border new backgroun

Re: Strange Static Analyzer Warning

On Dec 11, 2013, at 10:25:42, Keary Suska wrote: > I am getting a warning that I wasn't getting before, in Xcode 4.3.3 LLVM 3.1: > "Potential leak of an object allocated on line 139", with two sub-warnings: > 1) "Method returns an Objective-C object with a +1 retain count" (highlights > kDMTab

Re: Strange Static Analyzer Warning

On Dec 11, 2013, at 10:25 AM, Keary Suska wrote: > In this method: > > - (void) drawBezelWithFrame:(NSRect)frame inView:(NSView *)controlView { > if (self.state == NSOnState) { > // If selected we need to draw the border new background for selection > (otherwise we will use default back col

Strange Static Analyzer Warning

(I have been trying to send this to xcode-users, but for some reason it won't go through, although it is not entirely off-topic for this list) In this method: - (void) drawBezelWithFrame:(NSRect)frame inView:(NSView *)controlView { if (self.state == NSOnState) { // If selected we need to

Re: Static Analyzer is confusing me

On Feb 28, 2011, at 22:47, Gerriet M. Denkmann wrote: > Why does this error message go away when I add: > #define MAKE_BUG_DISAPPEAR1 3 > > Why does it NOT go away with: > #define MAKE_BUG_DISAPPEAR1 2 // or anything less than 3 ? What is so > magical about 3? I'

Static Analyzer is confusing me

%lu] = %lu\n", (unsigned long)i, (unsigned long)bbb[i]); // <--- Pass-by-value argument in function call is undefined }; } @end The Static Analyzer says: " Pass-by-value argument in function call is undefined", which I just plainly do not understand. Why

Re: Still another static analyzer (and LLVM parser) mistake

Matt Neuburg (m...@tidbits.com) on 2010-07-12 20:16 said: >There's no warning if you do this: > >NSArray* arr = [NSArray arrayWithObjects: @"howdy"]; > >GCC's parser is smart enough to know that the missing nil terminator is just >asking for trouble. FWIW, there are a bunch of compiler warnings t

Re: Still another static analyzer (and LLVM parser) mistake

On Mon, Jul 12, 2010 at 5:16 PM, Matt Neuburg wrote: > There's no warning if you do this: > > NSArray* arr = [NSArray arrayWithObjects: @"howdy"]; > > GCC's parser is smart enough to know that the missing nil terminator is just > asking for trouble. Have you filed a bug? http://www.llvm.org/bugs

Re: Another static analyzer mistake

You should file defects using or , or email the clang list () or Xcode list to report issues like these. -Shawn ___ Cocoa-dev mailing list (Cocoa-de

Still another static analyzer (and LLVM parser) mistake

There's no warning if you do this: NSArray* arr = [NSArray arrayWithObjects: @"howdy"]; GCC's parser is smart enough to know that the missing nil terminator is just asking for trouble. m. -- matt neuburg, phd = m...@tidbits.com, A fool + a tool + an autorelease p

Another static analyzer mistake

This, rightly, warns of a leak: MPMoviePlayerViewController* mpvc = [[MPMoviePlayerViewController alloc] initWithContentURL:urlurl]; This does not: MPMoviePlayerViewController* mpvc = [[MPMoviePlayerViewController alloc] initWithContentURL:urlurl]; [self presentMoviePlayerViewControllerAnima

Re: static analyzer

her connection:didFailWithError: or >>> connectionDidFinishLoading:. (My code and memory management come right out >>> of Apple's own examples here.) I know how NSURLConnections work; the static >>> analyzer doesn't. But I would hardly call that a bug. >>

Re: static analyzer

nd memory management come right out >> of Apple's own examples here.) I know how NSURLConnections work; the static >> analyzer doesn't. But I would hardly call that a bug. > >I would call it potentially dangerous code. It's much better, IMO, to >place the connection into

Re: static analyzer

On Wed, Jul 7, 2010 at 2:33 PM, Matt Neuburg wrote: > On or about 7/7/10 11:17 AM, thus spake "Bill Bumgarner" : > >> I missed the OP's post >> >> If the static analyzer is barfing up a false positive, please report it >> (http://bugreport.apple.co

Re: static analyzer

Le 7 juil. 2010 à 20:35, Bill Bumgarner a écrit : >> Is that generally true? I mean, first of all, false positives are a >> well-known phenomenon with this static analyzer (the Web page at llvm.org >> talks about this). Second, they do no harm. I get a false positive in *any*

Re: static analyzer

On Jul 7, 2010, at 11:33 AM, Matt Neuburg wrote: > On or about 7/7/10 11:17 AM, thus spake "Bill Bumgarner" : > >> I missed the OP's post >> >> If the static analyzer is barfing up a false positive, please report it >> (http://bugreport.apple.

static analyzer

On or about 7/7/10 11:17 AM, thus spake "Bill Bumgarner" : > I missed the OP's post > > If the static analyzer is barfing up a false positive, please report it > (http://bugreport.apple.com/ works fine). Is that generally true? I mean, first of all, false

Re: How to allocate and delegate; or how to keep GC and the static analyzer happy

; otherwise how would that object's methods get called later on? Either it's a delegate of another object (an NSURLConnection or NSTimer or whatever) or it starts a new thread to run one of its methods. Either way, there are references to the object that keep it alive. 2. The stati

Re: How to allocate and delegate; or how to keep GC and the static analyzer happy

On Oct 10, 2009, at 2:25 AM, Glen Low wrote: Not necessarily. In a pathological but presumably legit case, whatever happens in initDelegate: might only form a weak reference to the Something object, thus the Something object would be subject to GC. That's true, although unlikely. In that

Re: How to allocate and delegate; or how to keep GC and the static analyzer happy

Something object would be subject to GC. Or the thread etc. could somehow fail and never call finishWithSomething: (thus leaking the Something object). The main point is that I don't think I can rely on anything keeping a reference to the newly allocated Something object. 2. The static an

Re: How to allocate and delegate; or how to keep GC and the static analyzer happy

s get called later on? Either it's a delegate of another object (an NSURLConnection or NSTimer or whatever) or it starts a new thread to run one of its methods. Either way, there are references to the object that keep it alive. 2. The static analyzer in Xcode 3.2 doesn't like t

How to allocate and delegate; or how to keep GC and the static analyzer happy

of finishWithSomething, there are no references to the object, so it may be collected. 2. The static analyzer in Xcode 3.2 doesn't like the construction, thinking that the object is leaking from the start method. Of course I could keep a reference to the something object in a field o

Re: Static Analyzer Question

On Sep 29, 2009, at 8:00 PM, Dave DeLong wrote: To continue a bit on this idea, I believe that the static analyzer only analyzes a single method at a time. I don't believe it recurses into called methods to do analysis. (Can any of the clang- sa folks confirm this?) It will pe

Re: Static Analyzer Question

To continue a bit on this idea, I believe that the static analyzer only analyzes a single method at a time. I don't believe it recurses into called methods to do analysis. (Can any of the clang-sa folks confirm this?) Dave On Sep 29, 2009, at 6:31 PM, Jens Alfke wrote: On Sep 29,

Re: Static Analyzer Question

On 30 Sep 2009, at 09:13, Greg Parker wrote: The static analyzer tries to enforce Cocoa's memory management convention, where the retain-edness of the return value depends on the name of the method. By that convention, if the method name contains "new" or "copy" o

Re: Static Analyzer Question

Gentlemen; YES Bingo! + newWidgetID I love how Cocoa can so drive you crazy and then when insight happens it's often nearly painful in its elegance and simplicity… Breathtaking sometimes…. Thank-you all, Steve On Sep 29, 2009, at 5:12 PM, Steve Cronin wrote: "…. Object with +0 retain c

Re: Static Analyzer Question

On Sep 29, 2009, at 5:12 PM, Steve Cronin wrote: "…. Object with +0 retain counts returned to caller where a +1 (owning) retain count is expected" this is shown at the end of a particular method. I think this means the method has a name that by convention indicates that it returns a refer

Re: Static Analyzer Question

On Sep 29, 2009, at 5:12 PM, Steve Cronin wrote: This is the only method that Clang has an issue with… Why does Clang believe that an 'owning retain count is expected' if the method is never called? Why is Clang picking on this one method which mirrors the mechanics of so many others? Cla

Re: Static Analyzer Question

retain count is expected' if the method is never called? Why is Clang picking on this one method which mirrors the mechanics of so many others? The static analyzer tries to enforce Cocoa's memory management convention, where the retain-edness of the return value depends on the nam

Re: Static Analyzer Question

what's the name of the actual method it's complaining about? Steve Cronin wrote: Folks; I have a Clang issue that is making me a little crazy. I have a modestly complex Core Data application with several thousand lines of code. I've run Clang and at this point I have only one issue: "…. Ob

Static Analyzer Question

Folks; I have a Clang issue that is making me a little crazy. I have a modestly complex Core Data application with several thousand lines of code. I've run Clang and at this point I have only one issue: "…. Object with +0 retain counts returned to caller where a +1 (owning) retain count is

Re: Static Analyzer and Core Foundation

Le 19 sept. 2009 à 02:25, Steve Cronin a écrit : Luke; I've adapted the code to accomodate your's and Chris' answer to question 2. Here's the entire method, which now shows not static analyzer issues but I still would like to understand why not. + (NSDictionary *

Re: Static Analyzer and Core Foundation

On Sep 18, 2009, at 5:25 PM, Steve Cronin wrote: Is this the 'best' this can be? You need to call CFRelease on 'mdi', right after releasing 'arrayRef'. I don't know why the analyzer isn't reporting that as a leak — you could file a bug report. —Jens

Re: Static Analyzer and Core Foundation

Luke; I've adapted the code to accomodate your's and Chris' answer to question 2. Here's the entire method, which now shows not static analyzer issues but I still would like to understand why not. + (NSDictionary *)metadataForFilePath:(NSString *)thisPath {

Re: Static Analyzer and Core Foundation

There's not enough code here to give a good answer to question 1. Luke On Sep 18, 2009, at 4:39 PM, Steve Cronin wrote: Luke; OK thank-you for that answer to question 2! Any thoughts on question 1? Steve On Sep 18, 2009, at 6:36 PM, Luke the Hiesterman wrote: Line 44 creates 2 objects, one

Re: Static Analyzer and Core Foundation

On 18 Sep 2009, at 4:33 PM, Steve Cronin wrote: Alert - potential boneheaded-ness lies ahead - please be gentle. I'll be the first to admit that I'm much happier in ObjC than C… I thought I would try static analysis and see what turned up. On the whole I must say I'm pleased but this one has

Re: Static Analyzer and Core Foundation

Luke; OK thank-you for that answer to question 2! Any thoughts on question 1? Steve On Sep 18, 2009, at 6:36 PM, Luke the Hiesterman wrote: Line 44 creates 2 objects, one goes into the dictRef, the other is not assigned to a variable, but is used only as the second argument to MDItemCopyAt

Re: Static Analyzer and Core Foundation

Line 44 creates 2 objects, one goes into the dictRef, the other is not assigned to a variable, but is used only as the second argument to MDItemCopyAttributes. The object that you create inside that call is never released. Luke On Sep 18, 2009, at 4:33 PM, Steve Cronin wrote: Folks; Ale

Static Analyzer and Core Foundation

Folks; Alert - potential boneheaded-ness lies ahead - please be gentle. I'll be the first to admit that I'm much happier in ObjC than C… I thought I would try static analysis and see what turned up. On the whole I must say I'm pleased but this one has me questioning my basic understanding