[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiV+yL5qhm5FbeKz3FV6Zdi4oRv7rr3b_=16tfmwUMWFA@mail.gmail.com>
Date: Sun, 17 Nov 2024 14:58:05 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Laight <David.Laight@...lab.com>
Cc: Vincent Mailhol <mailhol.vincent@...adoo.fr>, Yury Norov <yury.norov@...il.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>, Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-sparse@...r.kernel.org" <linux-sparse@...r.kernel.org>,
Rikard Falkeborn <rikard.falkeborn@...il.com>
Subject: Re: [PATCH v4 1/2] compiler.h: add const_true()
On Sun, 17 Nov 2024 at 14:38, David Laight <David.Laight@...lab.com> wrote:
>
> I wonder if it reads better (and without extra comments) if the (long)
> cast is removed and the 'callers' are required to generate 'long' args.
I think that's much less obvious, actually. You'd have to explain why
it has those odd long constants now.
Also, technically it's not even really about "long", but "intptr_t",
which doesn't have a simple constant representation.
We're using "long" in this context because we don't want to have even
more dependencies in compiler.h - but I do think that means that the
cast is at least conceptually the proper way to do things: it's how
you'd do it in some user-mode header if you do this (as opposed to our
kernel model where we generate all these things from scratch anyway).
The "0*!(x)" is admittedly kind of ugly, and might be prettier as
"0&&(x)". Same number of characters, but technically one op less and
not mixing booleans and integer ops.
But honestly, nobody is ever going to look at the internals anyway
once it's all in there and works.
Linus
Powered by blists - more mailing lists