> On Mar 15, 2016, at 10:30 AM, Jens Alfke <j...@mooseyard.com> wrote: > > I’ve got two inexplicable static analyzer warnings, which hinge on the > analyzer believing that an Obj-C ivar being nil. (In one case it's passed to > a parameter declared nonnull, in the other it’s tested for nil in an ‘if’, > and the bad situation happens inside the body of the ‘if’.) But in neither > case does the analyzer know that the ivar is nil.
One thing to note is that the analyzer doesn’t treat a parameter with a ‘nonnull’ type qualifier as definitely not nil. In other words, marking a parameter ‘nonnull' is not the same (in the analyzer’s view) as asserting that the parameter is not nil at the beginning of the method. The analyzer does this in order to not lose coverage on paths where ‘nonnull’ parameters are defensively checked for nil — it is exactly these kinds of error-handling/recovery paths where static analysis is most valuable. > What kinds of assumptions does the static analyzer make about ivars? It can’t > just assume that any ivar may be nil on entry to any method, because that > would produce enormous numbers of false positives. In general, the analyzer does not make any assumptions about the whether an ivar is nil or not on method entry (unless the analyzer is analyzing the method “inlined” and it sees that the caller set the ivar to a known value). But the analysis strategy is to only warn about a nullability violation when the analysis thinks a value is definitely nil. This means that the weak assumption that the ivar may (not must) be nil will typically not result in a warning. However, as Ken Thomases noted earlier in the thread, when the analyzer doesn’t know whether a value is nil or not (i.e., it may be nil) it treats an explicit comparison against nil (e.g, ‘if’) as an indicator that the programmer has some expectation that the value could be nil. In this case, it explores the nil and not-nil paths separately: one path where the value is definitely nil and one path where it is definitely not nil. (If the analyzer already knows that the value is definitely non-nil it won’t explore the nil path.) This means that a redundant nil check in a situation where the programmer knows a value is definitely not nil but the analyzer thinks it may possibly be nil can result in an unexpected nullability warning. This might be an explanation for what you are seeing, in which you case you could get rid of the warning by removing the ‘if' (if possible) or adding an assertion that the value is not nil. > Likewise, it can’t assume that another thread randomly sets ivars to nil > concurrently with the current thread. But those seem to be the only > explanations for the warnings I’m getting. The analyzer doesn’t do any reasoning about potential interference from other threads. 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
