From: Alessandro Rubini <rubini@gnudd.com>
To: uwe@kleine-koenig.org
Cc: gregkh@linuxfoundation.org, corbet@lwn.net,
linux-kernel@vger.kernel.org, thierry.reding@gmail.com,
Michal.Vokac@ysoft.com, akpm@linux-foundation.org,
kernel@pengutronix.de
Subject: Re: [PATCH RFC] err.h: document that PTR_ERR should only be used if IS_ERR returns true
Date: Mon, 15 Oct 2018 11:37:08 +0200 [thread overview]
Message-ID: <20181015093708.GA22876@mail.gnudd.com> (raw)
In-Reply-To: <20181014202807.16412-1-uwe@kleine-koenig.org>
Hello.
> during a review I claimed that PTR_ERR should only be used if IS_ERR was
> already checked. The rationale isn't obvious though and Thierry
> suggested to keep the code as is and not introduce an IS_ERR check.
The rationale is the same ch11 you linked to: "any other value
is a valid pointer". It isn't usefult to convert to long sth that
your are not using as a long. You should not pass it to strerror(-err)
for example.
OTOH I admit you can compare any value with -EINVAL, after PTR_ERR.
But in general you first detect the error condition and then split
among error (or print a message according to the exact value.
> maybe something like "On an Alpha it is important because
> not doing it results in a bus error there."
No, nothing that exotic.
You said:
> Thierry suggested to keep the code as is and not introduce an IS_ERR check.
I wonder where. Sure no extra check in the header, that would be
extra wasted time in every caller. If it's a specific caller place,
it may make sense to avoid the check, I don't know the details.
As for the specific patch you propose, I'm unsure it's useful. Maybe
we should remember that "this returns the equivalent of "-errno" if
IS_ERR() is true", but I'm personally not much for overcommenting:
It's a simple cast and there are a zillion users to see how exactly
this works if anyone is uncertain.
Regards
/alessandro
next prev parent reply other threads:[~2018-10-15 9:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-14 20:28 [PATCH RFC] err.h: document that PTR_ERR should only be used if IS_ERR returns true Uwe Kleine-König
2018-10-15 9:37 ` Alessandro Rubini [this message]
2018-10-15 9:46 ` Uwe Kleine-König
2018-10-16 18:06 ` Al Viro
2018-10-16 19:29 ` Uwe Kleine-König
2018-10-16 20:10 ` Alessandro Rubini
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=20181015093708.GA22876@mail.gnudd.com \
--to=rubini@gnudd.com \
--cc=Michal.Vokac@ysoft.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=thierry.reding@gmail.com \
--cc=uwe@kleine-koenig.org \
/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.