From: Dan Carpenter <dan.carpenter@oracle.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.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 12:03:26 +0300 [thread overview]
Message-ID: <20210623090325.GA2116@kadam> (raw)
In-Reply-To: <YNKdqFNSrSBXVNqo@pendragon.ideasonboard.com>
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.
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,
dan carpenter
next prev parent reply other threads:[~2021-06-23 9:03 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 [this message]
2021-06-23 12:56 ` Laurent Pinchart
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=20210623090325.GA2116@kadam \
--to=dan.carpenter@oracle.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=kernel-janitors@vger.kernel.org \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=laurent.pinchart@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.