archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <>
To: Dan Carpenter <>
Cc: Tomi Valkeinen <>,
	Kieran Bingham <>,
	Mauro Carvalho Chehab <>,
	Hans Verkuil <>,
	Sakari Ailus <>,,
Subject: Re: [PATCH] media: v4l2-subdev: fix some NULL vs IS_ERR() checks
Date: Wed, 23 Jun 2021 15:56:10 +0300	[thread overview]
Message-ID: <YNMvarFl/> (raw)
In-Reply-To: <20210623090325.GA2116@kadam>

On Wed, Jun 23, 2021 at 12:03:26PM +0300, Dan Carpenter wrote:
> On Wed, Jun 23, 2021 at 05:34:16AM +0300, Laurent Pinchart wrote:
> > 
> > Do you think an annotation could still help, by making it explicit in
> > headers whether a function returns NULL or an error pointer, thus
> > helping developers get it right in the first place ?
> Not really.  It wouldn't help with Smatch.  I really think error pointer
> bugs are handled pretty well currently.  Sometimes I have seen syzbot
> find them before the static checkers but I don't see them affecting
> users and production kernels.

I meant to ask if it would be useful for developers, not for smatch.
When I use a function and have to figure out whether to use IS_ERR() or
!= NULL, I first look at the header, and most of the time I then need to
find the corresponding implementation, wherever it may be. If we had an
annotation, the second step could be skipped. Of course the annotation
would need to match the implementation, and that's an area where smatch
could help.

> There are few other things that Smatch looks for like passing positives,
> valid pointers or NULLs to PTR_ERR().  I do wish that when functions
> return a mix of negative error codes, 0 and 1 that they had comment
> explaining what the 1 means.


Laurent Pinchart

  reply	other threads:[~2021-06-23 12:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22 14:31 [PATCH] media: v4l2-subdev: fix some NULL vs IS_ERR() checks Dan Carpenter
2021-06-22 15:08 ` Laurent Pinchart
2021-06-22 15:58   ` Dan Carpenter
2021-06-23  2:29     ` weiyongjun (A)
2021-06-23  2:34     ` Laurent Pinchart
2021-06-23  9:03       ` Dan Carpenter
2021-06-23 12:56         ` Laurent Pinchart [this message]
2021-06-22 20:01 ` Sakari Ailus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YNMvarFl/ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).