Re: Potential static analysis ideas

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, Jul 26, 2021 at 10:55 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Actually, I don't think so ... we have NULL return all over the inode
> and dentry code.  It's a legitimate return for "I couldn't find what
> you asked for" or in the dentry case "I have no current entry".  The
> error returns are usually an explicit "there was some problem during
> the lookup".

Absolutely. We have several cases of "valid pointer, NULL _or_ error pointer".

Some of those things are not always about error pointers either. An
example of this same kind of "three-way answer" is get_cached_acl(),
which can return

 - an actual honest-to-goodness real posix_acl pointer

 - NULL for "there is no ACL data"

 -  special value for "no cached data", need to ask the filesystem

That particular case isn't using the error pointers, but it's very
similar in nature to that "this is an explicit error" vs "don't know"
kind of thing.

Anyway, gcc has this completely ass-backwards "nonnull" function
attribute, sadly it's pure garbage. It's not a "type of this pointer"
thing, it's a "this function does not take NULL as argument X" thing.

We could relatively easily add a "__nonnull" type attribute  (and
"__errptr") and parse it in sparse, but it would be _all_ over the
place, and without real compiler support it's probably not worth it
(people already don't run sparse all that much, and a lot of the
things sparse can warn about are too verbose to be be used in
practice).

But in _theory_ it would be lovely to be able to say "this pointer
cannot be NULL" or "this pointer can be an error pointer", but I
suspect it really ends up being everywhere and more pain than gain.

                   Linus