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 perform analysis for statically bound calls, which is restricted to functions, not methods. As you suspect, since method calls are dynamically bound, the analyzer has no way of knowing what actual implementation will be invoked at runtime. Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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, 2009, at 5:12 PM, Steve Cronin wrote: Why does Clang believe that an 'owning retain count is expected' if the method is never called? Objective-C is a dynamic enough language that there is no way to tell at compile time whether a method is reachable or not. Even if that selector never appears in your code, it could be constructed at runtime, or your code could load a plugin bundle that calls that selector. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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" or "alloc" then the return value is retained and the caller is expected to release it; otherwise the return value is autoreleased and the caller is not expected to release it. I had a similar problem with the static analyzer: +(NSSet *)keyPathsForValuesAffectingCanCopyRsrcFork There is a "Copy" in the name of the method, but the real name (as should be considered by clang) is: +keyPathsForValuesAffecting The "copy" is just part of the . This is a bit confusing. Maybe Clang should be told about method names which contain a in it's name. Kind regards, Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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 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 reference the caller must release — i.e.
a prefix of "alloc" or "copy" or "mutableCopy"
+ (NSString *) fooBar {
NSString *result = @"";
…..
if (x) {
result = @"1";
...
} else {
result = @"2";
}
return result;
}
What's the actual name (not 'fooBar')?
Why does Clang believe that an 'owning retain count is expected' if
the method is never called?
Objective-C is a dynamic enough language that there is no way to
tell at compile time whether a method is reachable or not. Even if
that selector never appears in your code, it could be constructed at
runtime, or your code could load a plugin bundle that calls that
selector.
—Jens
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
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 reference the caller must release — i.e. a prefix of
"alloc" or "copy" or "mutableCopy"
+ (NSString *) fooBar {
NSString *result = @"";
…..
if (x) {
result = @"1";
...
} else {
result = @"2";
}
return result;
}
What's the actual name (not 'fooBar')?
Why does Clang believe that an 'owning retain count is expected' if
the method is never called?
Objective-C is a dynamic enough language that there is no way to tell
at compile time whether a method is reachable or not. Even if that
selector never appears in your code, it could be constructed at
runtime, or your code could load a plugin bundle that calls that
selector.
—Jens___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
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? Clang-sa decides what the retain behavior should be based on the method's name. Does the method name by any chance contain a substring like "new" or "copy"? There are some macros in some header or other which you can use to tell Clang that a method should have some other behavior than what it guesses from the name, although they aren't as flexible as I might like. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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.
The deal is that, over time, I have isolated this method and at this
moment there are NO methods which call it.
I cannot leave it like this - this isolation is a result of honing
in on the Clang issue...
A very common pattern for my application looks like this:
+ (NSString *) fooBar {
NSString *result = @"";
…..
if (x) {
result = @"1";
...
} else {
result = @"2";
}
return result;
}
Yes this is a class method - I use this pattern for both class and
instance methods.
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?
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" or "alloc" then the return value is retained and the
caller is expected to release it; otherwise the return value is
autoreleased and the caller is not expected to release it.
What exactly is the name of the method the analyzer complains about?
I'm guessing that name includes "new" or "copy" or "alloc", and the
similar methods that the analyzer likes do not.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
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:
"…. 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.
The deal is that, over time, I have isolated this method and at this
moment there are NO methods which call it.
I cannot leave it like this - this isolation is a result of honing in
on the Clang issue...
A very common pattern for my application looks like this:
+ (NSString *) fooBar {
NSString *result = @"";
…..
if (x) {
result = @"1";
...
} else {
result = @"2";
}
return result;
}
Yes this is a class method - I use this pattern for both class and
instance methods.
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?
Any thoughts appreciated!
Steve
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
This email sent to r...@rols.org
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
