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
