Re: [PATCH RFC] err.h: document that PTR_ERR should only be used if IS_ERR returns true

[Alessandro Rubini]

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