This looks like it might be a problem, added to my TODO list.

Doesn't look like a bug, we don't always allocate new rule, (but if we do it's never NULL because M_WAITOK), so it makes sense to NULL-check it.

This check is just wrong. Yes, we use *m before checking it, but that's because pf_test6() can change it.

Also seems to be wrong, we can only hit the NULL check from places where newpa is allocated.
We can probably get rid of the NULL check, especially considering that free() checks for NULL anyway.

size2 is never NULL, so we can get rid of the NULL check (perhaps adding an assert at the top of the function.

All of the "tl" ones are bogus. The NFSM_BUILD() and NFSM_DISSECT() macros
set tl to point to a block of memory the size of the argument. It is then incremented
through the block, sometimes skipping some bytes.

The case where it is used it is valid and non-null.

bp is only used when n > 0 and it is always valid and non-null when n > 0.

It is initialized before it is used.

Addressed in https://svnweb.freebsd.org/changeset/base/295708.

Adressed in https://svnweb.freebsd.org/changeset/base/295708.

This is not an issue, but the code has been cleaned up such that the warning will not show up anymore.
This is done in https://svnweb.freebsd.org/changeset/base/295709.

False positive. If net != NULL then stcb =! NULL.

False positive.

False positive.

Addressed in https://svnweb.freebsd.org/changeset/base/295710.

Addressed in https://svnweb.freebsd.org/changeset/base/295710.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

False positive.

The comment below tries to explain it: the check is bogus and is intended to prevent the compiler from making the dtrace_getarg() call a tail call. So this is a false positive.

I wonder if that trick is really reliable though. The check is only false if undefined behaviour has been invoked.

False positive. panic() doesn't return.

False positive; nspec > 0 => spec != NULL.

False positive; the code is assuming that enab->dten_ndesc > 0 implies that enab->dten_desc != NULL.

It does seem excessive, but I don't see why it might be wrong. It's also an assertion condition.

False positive

False positive

The bug reported can not happen, since the function is not really working as expected.
This is fixed in https://svnweb.freebsd.org/changeset/base/295771.

The bug reported can not happen, since the function is not really working as expected.
This is fixed in https://svnweb.freebsd.org/changeset/base/295771.

False positive, but addressed in https://svnweb.freebsd.org/base?view=revision&revision=295759

False positive. We always have a bp for a DELETE ccb, but the code is twisty enough that the static analyzer missed it.

False positive. serial_buf is always != NULL when have_serial is true, which we check in this loop.

It is initialized before used.

It is initialized before being used.

The if and else do the same thing, which is silly but not broken. I believe this
was inherited from the old NFS client, so I left the code that way, although I
did notice this.

This one I don't understand. "iv" is declared local to the function and is used
within the function, so I have no idea why it thinks there is a scope issue?

False positive, since the code checks for nfsd_master_proc != NULL
and then procp == nfsd_master_proc --> procp cannot be NULL.

It is initialized before being used.

It is initialized before being used.

Also a false positive. The only time nd == NULL is when the function is
called with CLOPS_RENEW. This code block isn't executed for CLOPS_RENEW.

Does no harm, but I'll fix it to simplify the loop condition where it occurs.

False positive: baddr != NULL is tested and only possible for vbp != NULL

Looks like a false positive: The value read into cp cannot be NULL unless there was a malloc error during driver attach (which had made the attach fail).

This is false positive, but moving "structsize = sizeof(elf_kinfo_proc_t);" before the check would fix this warning.
Not yet fixed / silenced this warning.

This is false positive, p used as dummy parameter at this call.

Hm, no idea what might be wrong here. False positive, perhaps? I'd appreciate if someone took a look at this.

This one looks like a valid bug: ufs_dir_dd_ino() should set *dd_vp to NULL before returning in all cases.