[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20181016201028.GA3257@mail.gnudd.com>
Date: Tue, 16 Oct 2018 22:10:28 +0200
From: Alessandro Rubini <rubini@...dd.com>
To: u.kleine-koenig@...gutronix.de
Cc: viro@...IV.linux.org.uk, 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
Me:
>> > 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.
Al Viro:
>>
>> 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...
Sure. I was talking about selecting among errors in the error path,
after you left the fast path jumping away with IS_ERR().
(in short, I agree).
Uwe kleine-koenig
> And what do you do if you see a
>
> p = somefunc(...);
> if (PTR_ERR(p) == -ENOENT)
>
> without first checking for IS_ERR(p)?
I see no problem. The original suggestion (only use if IS_ERR), which
was mine, refers to doing error management in error cases. Sure
if you know the return value is valid or -ENOENT you don't need to verify
it is negative before comparing with -2.
Both PTR_ERR and ERR_PTR are just a cast to prevent a warning
(and tell the reader that you convert from err to ptr or vv), so
I think the two are equivalent. Al's version above is maybe cleaner,
but we are bikeshedding, IMHO.
best
/alessandro
Powered by blists - more mailing lists