Re: Analyzer warning about garbage with double return values
Re: Analyzer warning about garbage with double return values
- Subject: Re: Analyzer warning about garbage with double return values
- From: Roland King <email@hidden>
- Date: Wed, 2 Sep 2009 23:30:25 +0800
Hey Bill,
Let me say one thing, you've said for the last few months on the Cocoa
list that "if you have Snow Leopard the toolchain is vastly
improved" (I may be paraphrasing there) and it is, it's eye-opening, I
finally got it installed a couple of days ago and everything is better
(the new documentation system is great) it's just all better. I have
just run 3 of my projects through this analyzer and found 2 bugs and
about 6 places I just broke the rules intentionally and it shamed me
into fixing them.
You're right, this is an edge case, my only real desire is probably
that the message should say 'the object *may* be nil' instead of '*is*
nil' which would get you to consider the code which is setting it and
figure out if it really is going to set it in every case, I'll file a
report with that suggestion in it. I had already put an if( object )
<do thing> else <recover from bogus condition I really don't expect>
in there and documented it because you're right, I've taken as read
that the touches array always has something in it and that variable
will always be set, but the static analyser has shown it's not so and
it's a condition I should code against.
Thanks by the way to all the people at Apple who worked on the Snow
Leopard dev tools, I'm loving them already.
On 02-Sep-2009, at 11:09 PM, Bill Bumgarner wrote:
On Sep 2, 2009, at 4:28 AM, Roland King wrote:
I have a similar issue - in this case I'm setting a variable to nil
early in the routine, just when I declare it, however it's
guaranteed to get set later to something else (whilst iterating a
set of touches which are guaranteed not to be empty). I get the
same message about sending messages to nil as the static analyzer
can't prove to itself the variable is ever reset.
Welcome to the exciting world of edge cases galore!
The static analyzer generally does a wonderful job of indicating
potential problems. There are a handful of cases where it doesn't
get the rules quite right; typically with exceptional cases and, in
particular, in cases where state is only guaranteed because the docs
say it'll work that way and code you don't have is implemented that
way.
Please file a bug via http://bugreport.apple.com/. The component
is "llvm - checker".
Note that this is one area where it isn't totally clear how the
analyzer should be fixed. In particular, while the docs say that
the touches are guaranteed to not be empty, what if a bug -- yours
or Apple's -- causes them to be? Would a better solution be to add
an assert() at the beginning of the method, one that isn't compiled
into production code? A strong argument could be made for that
being a preferable solution in that it explicitly quantifies the
documented behavior into the code.
(Even for the handful of static analysis false positives, the tool
has proven to be incredibly valuable. A total game changer in my
code, certainly.)
b.bum
_______________________________________________
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
_______________________________________________
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