[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181016192928.pinjwxfors4reigh@pengutronix.de>
Date: Tue, 16 Oct 2018 21:29:28 +0200
From: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Alessandro Rubini <rubini@...dd.com>, Michal.Vokac@...ft.com,
corbet@....net, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org, thierry.reding@...il.com,
kernel@...gutronix.de, akpm@...ux-foundation.org
Subject: Re: [PATCH RFC] err.h: document that PTR_ERR should only be used if
IS_ERR returns true
On Tue, Oct 16, 2018 at 07:06:51PM +0100, Al Viro wrote:
> On Mon, Oct 15, 2018 at 11:37:08AM +0200, Alessandro Rubini wrote:
>
> > 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.
>
> if (IS_ERR(p) && PTR_ERR(p) == -ENOENT)
> instead of
> if (p == ERR_PTR(-ENOENT))
>
> is ugly, obfuscating what's going on for no good reason and I'm going
> to keep killing those every time I run into one...
And what do you do if you see a
p = somefunc(...);
if (PTR_ERR(p) == -ENOENT)
without first checking for IS_ERR(p)? Another alternative is
if (PTR_ERR_OR_ZERO(p) == -ENOENT)
? In your eyes, should they all be converted to
if (p == ERR_PTR(-ENOENT))
?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Powered by blists - more mailing lists