From: Linus Torvalds <torvalds@linux-foundation.org>
To: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Cc: Yury Norov <yury.norov@gmail.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
linux-kernel@vger.kernel.org, linux-sparse@vger.kernel.org,
Rikard Falkeborn <rikard.falkeborn@gmail.com>
Subject: Re: [PATCH v2] linux/bits: simplify GENMASK_INPUT_CHECK()
Date: Mon, 11 Nov 2024 09:32:12 -0800 [thread overview]
Message-ID: <CAHk-=wh5SNYdgx8-X+ggHP+ojbG2F7oyt3TLmMgqejYd5zn0Aw@mail.gmail.com> (raw)
In-Reply-To: <20241111164743.339117-2-mailhol.vincent@wanadoo.fr>
On Mon, 11 Nov 2024 at 08:48, Vincent Mailhol
<mailhol.vincent@wanadoo.fr> wrote:
>
> - introduce _statically_true(), taking inspiration from
> statically_true() as introduced in commit 22f546873149 ("minmax:
> improve macro expansion and type checking")
So I really think this needs an explanation of what the difference is
when using __builtin_constant_p() vs using __is_constexpr(), and why
the existing statically_true() didn't work for you.
In my experience, __is_constexpr() is too limited, because it
literally requires a syntactically constant expression.
In contrast, __builtin_constant_p() often works for things that aren't
constant expressions, but that evaluate to constants at build time.
For example, I had a test patch that used statically_true() to do
things like "if the size of a user copy is a multiple of the size of
'long', call a simplified version without the byte copy part".
And sure, __is_constexpr() gets it right for completely constant
arguments. But __builtin_constant_p() will actually trigger not only
those, but also when the argument is something like
if (copy_to_user(buf, values, n * sizeof(u64)))
because it sees that even if "n * sizeof(u64)" is not a constant, the
"is this a multiple of 'long' size" _is_ constant.
IOW, I think __builtin_constant_p() is preferable, because it not only
doesn't expand to the horror that is __is_constexpr(), it also
generally does better when you have the flexibility to use it.
Of course, I do think that the use in BUILD_BUG_ON_ZERO() requires
something that is more statically reliable, and so __is_constexpr()
that is purely syntactic is probably the right thing to have. So I'm
not objecting to your _statically_true() per se. I just think this
needs a big comment about why we have both versions, and when to use
one over the other.
Linus
prev parent reply other threads:[~2024-11-11 17:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-11 16:43 [PATCH v2] linux/bits: simplify GENMASK_INPUT_CHECK() Vincent Mailhol
2024-11-11 17:32 ` Linus Torvalds [this message]
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='CAHk-=wh5SNYdgx8-X+ggHP+ojbG2F7oyt3TLmMgqejYd5zn0Aw@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=luc.vanoostenryck@gmail.com \
--cc=mailhol.vincent@wanadoo.fr \
--cc=rikard.falkeborn@gmail.com \
--cc=yury.norov@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).