[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzjZqt-8HhvbvLb7s3vR_G3Hjmf=buKBBKTnmKm+KVK-Q@mail.gmail.com>
Date: Tue, 15 Sep 2015 16:52:20 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: John Stultz <john.stultz@...aro.org>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Steven Rostedt (Red Hat)" <rostedt@...dmis.org>,
Peter Zijlstra <peterz@...radead.org>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Michal Nazarewicz <mina86@...a86.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RFC][PATCH 5/5] abs(): Provide build error on passing 64bit
value to abs()
On Mon, Sep 14, 2015 at 10:22 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> I think this should be a compiletime_warning() - that will be visible enough.
So the problem with this is that by now most kernel developers are on 64-bit.
And that "sizeof(typeof(x)) > sizeof(long))" would effectively never
trigger on 64-bit architectures, so almost no core developers would
see it. Yes, it would be caught by buildbots etc, but that's really
not very convenient. The new errors would be noticed too late, because
the actual *developers* wouldn't see them.
(Not to mention that the "typeof()" in that expression is redundant ;)
So I think the "auto-expand to 's64' using __builtin_choose_expr()" is
the preferable model, and get rid of abs64() entirely. It has very few
uses.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists