> On Mar 15, 2016, at 1:27 PM, Wim Lewis <w...@omnigroup.com> wrote: > > > On Mar 15, 2016, at 12:14 PM, Jens Alfke <j...@mooseyard.com> wrote: >> I added the assertion to try to make the warning go away, but it doesn’t go >> away. However, if I move the assert call down to below the NSLog, the >> warning goes away. It looks as though the analyzer believes that calling >> NSLog can change _foo to nil somehow. > > It might be the assert() that is bringing the warning to light. If you have > code that considers the possibility of nil, then the analyzer assumes that it > could be nil. If your code doesn't consider the possibility of nil, then the > analyzer frequently won't, either.
You can get false positives like this if you use custom assertion macros in your project. In this case you would need to annotate the assertion handler (the part of the assertion macro that aborts when the check fails) with __attribute__((analyzer_noreturn)). This tells the analyzer to only consider flows on which the assertion holds. There are more details on how to do this at <http://clang-analyzer.llvm.org/annotations.html#custom_assertions <http://clang-analyzer.llvm.org/annotations.html#custom_assertions>>. Devin
_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (Xcode-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to arch...@mail-archive.com
