From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-media@vger.kernel.org, kernel-janitors@vger.kernel.org
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/KU1pGCG@pendragon.ideasonboard.com> (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.
--
Regards,
Laurent Pinchart
next prev parent 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YNMvarFl/KU1pGCG@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=dan.carpenter@oracle.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=kernel-janitors@vger.kernel.org \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=tomi.valkeinen@ideasonboard.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).