Re: Potential static analysis ideas

[Arnd Bergmann <arnd@arndb.de>]

On Sun, Jul 25, 2021 at 1:45 AM NeilBrown <neilb@suse.de> wrote:
> On Sun, 25 Jul 2021, Laurent Pinchart wrote:
> > >
> > > To make it work well, you need to know if frob() and/or the current
> > > function return an error code or not.  While you can use some heuristics
> > > (e.g. is there any return -Exxx), perhaps we can add an annotation to
> > > indicate if a function returns an error code, or an error pointer?
> >
> > https://lore.kernel.org/linux-media/YNMvarFl%2FKU1pGCG@pendragon.ideasonboard.com/
> >
> > I think it would be useful, if not for the tools, at least for
> > developers.
>
> Agreed.  I added some code to smatch so that I could annotate pointers to
> say if they are allowed to be NULL.  The implementation isn't perfect,
> but I love having that extra documentation about when I do or don't have
> to check for NULL.

I can think of four different annotations that limit what a pointer return from
a function can be:

a) either a valid pointer or NULL, but never an error pointer,
b) either a valid pointer or an error pointer, but not NULL,
c) always a valid pointer, never NULL or an error,
d) always NULL, but callers are expected to check for error pointers.

The last one is the tricky bit because there are a couple of subsystems
that intentionally return an opaque NULL pointer to indicate success
when the subsystem is compile-time disabled, and expect callers to not
dereference that pointer but instead pass it into other stubbed-out
interfaces. I think this one is rather specific to the kernel, but also really
useful to have in a static checker because everyone gets those wrong.

        Arnd