From: Arnd Bergmann <arnd@arndb.de>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
open list <linux-kernel@vger.kernel.org>,
Bob Peterson <rpeterso@redhat.com>,
linux@rasmusvillemoes.dk
Subject: Re: [PATCH v3] err.h: allow IS_ERR_VALUE to handle properly more types
Date: Thu, 11 Feb 2016 17:39:49 +0100 [thread overview]
Message-ID: <3104312.nOVEcCskuj@wuerfel> (raw)
In-Reply-To: <56BC31A6.4060102@samsung.com>
On Thursday 11 February 2016 08:00:54 Andrzej Hajda wrote:
> > I think the easiest way to express this would be to ensure that the argument
> > is 'unsigned long', like:
> >
> > #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
> > unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
>
> This way you will limit it only to unsigned long type, which seems too
> strict to me.
> I think the macro should accept all long enough unsigned types, otherwise we
> could end up with bunch of macros IS_ERR_VALUE_U32, IS_ERR_VALUE_ULL...
I think in practice we only care about 'int' and 'unsigned long', which are
the ones that 90% of the existing users pass in today. u32 has never worked
on 64-bit architectures so far, so we don't necessarily have to make it work.
As Al mentioned, most users of IS_ERR_VALUE are wrong anyway and should
just use 'if (err < 0)' or 'if (err)'.
We could also consider making just 'int' and 'unsigned long' allowed types
for the moment, and then change all users passing 'int' before forbidding them.
Arnd
next prev parent reply other threads:[~2016-02-11 16:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 14:58 [PATCH] err.h: allow IS_ERR_VALUE to handle properly more types Andrzej Hajda
2016-01-07 15:48 ` kbuild test robot
2016-01-28 8:27 ` [PATCH v2] " Andrzej Hajda
2016-02-02 6:23 ` Andrew Morton
2016-02-02 8:22 ` Andrzej Hajda
2016-02-03 0:33 ` Andrew Morton
2016-02-03 10:53 ` Andrzej Hajda
2016-02-03 13:15 ` [PATCH v3] " Andrzej Hajda
2016-02-04 12:40 ` Arnd Bergmann
2016-02-04 14:44 ` Andrzej Hajda
2016-02-04 15:00 ` Arnd Bergmann
2016-02-04 15:10 ` Arnd Bergmann
2016-02-04 18:59 ` Andrew Morton
2016-02-05 10:52 ` Arnd Bergmann
2016-02-08 8:45 ` Andrzej Hajda
2016-02-08 12:01 ` Arnd Bergmann
2016-02-09 1:44 ` Al Viro
2016-02-09 8:42 ` Andrzej Hajda
2016-02-10 21:01 ` Arnd Bergmann
2016-02-11 7:00 ` Andrzej Hajda
2016-02-11 16:39 ` Arnd Bergmann [this message]
2016-02-12 14:45 ` Andrzej Hajda
2016-02-11 21:14 ` Al Viro
2016-02-04 23:37 ` Rasmus Villemoes
2016-02-10 15:16 ` Guenter Roeck
2016-01-15 13:45 ` [PATCH] " Andrzej Hajda
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=3104312.nOVEcCskuj@wuerfel \
--to=arnd@arndb.de \
--cc=a.hajda@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=b.zolnierkie@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=m.szyprowski@samsung.com \
--cc=rpeterso@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox