> On Mar 15, 2016, at 11:59 AM, Devin Coughlin <[email protected]> wrote:
>
> One thing to note is that the analyzer doesn’t treat a parameter with a
> ‘nonnull’ type qualifier as definitely not nil.
It’s the other way around — I’m _calling_ a function (dispatch_async) with a
nonnull parameter declaration, but the analyzer has decided the variable I’m
passing might be nil, hence the warning. The code looks sort of like:
if (!_queue) { _queue = _otherQueue; }
dispatch_async(_queue, { … });
(Both _queue and _otherQueue are ivars typed as dispatch_queue_t.) I happen to
know that _otherQueue is non-nil, because I assign it in the -init method and
never modify it. But the analyzer seems to be deciding it might be nil, and
warns that I’m passing nil to dispatch_async.
> The analyzer doesn’t do any reasoning about potential interference from other
> threads.
Hm. The other inexplicable warning involves some tracing across method calls,
and part of what has to go wrong is that a specific method returns nil. The
method ends like:
… // at this point _foo can’t be nil
assert(_foo);
NSLog(@“%@: foo is %@“, self, _foo);
return _foo;
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.
—Jens _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com
This email sent to [email protected]
