All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Kees Cook <keescook@chromium.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Martin Uecker <Martin.Uecker@med.uni-goettingen.de>,
	Ingo Molnar <mingo@kernel.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	Rikard Falkeborn <rikard.falkeborn@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-doc@vger.kernel.org,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: [PATCH] linux/const.h: Explain how __is_constexpr() works
Date: Mon, 31 Jan 2022 12:43:57 -0800	[thread overview]
Message-ID: <20220131204357.1133674-1-keescook@chromium.org> (raw)

The __is_constexpr() macro is dark magic. Shed some light on it with
a comment to explain how and why it works.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Martin Uecker <Martin.Uecker@med.uni-goettingen.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-doc@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
Jon, since this is pure comment, do you want to take it through the docs tree?
---
 include/linux/const.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/include/linux/const.h b/include/linux/const.h
index 435ddd72d2c4..7122d6a1f8ce 100644
--- a/include/linux/const.h
+++ b/include/linux/const.h
@@ -7,6 +7,30 @@
  * This returns a constant expression while determining if an argument is
  * a constant expression, most importantly without evaluating the argument.
  * Glory to Martin Uecker <Martin.Uecker@med.uni-goettingen.de>
+ *
+ * Details:
+ * - sizeof() is an integer constant expression, and does not evaluate the
+ *   value of its operand; it only examines the type of its operand.
+ * - The results of comparing two integer constant expressions is also
+ *   an integer constant expression.
+ * - The use of literal "8" is to avoid warnings about unaligned pointers;
+ *   these could otherwise just be "1"s.
+ * - (long)(x) is used to avoid warnings about 64-bit types on 32-bit
+ *   architectures.
+ * - The C standard defines an "integer constant expression" as different
+ *   from a "null pointer constant" (an integer constant 0 pointer).
+ * - The conditional operator ("... ? ... : ...") returns the type of the
+ *   operand that isn't a null pointer constant. This behavior is the
+ *   central mechanism of the macro.
+ * - If (x) is an integer constant expression, then the "* 0l" resolves it
+ *   into a null pointer constant, which forces the conditional operator
+ *   to return the type of the last operand: "(int *)".
+ * - If (x) is not an integer constant expression, then the type of the
+ *   conditional operator is from the first operand: "(void *)".
+ * - sizeof(int) == 4 and sizeof(void) == 1.
+ * - The ultimate comparison to "sizeof(int)" chooses between either:
+ *     sizeof(*((int *) (8)) == sizeof(int)   (x was a constant expression)
+ *     sizeof(*((void *)(8)) == sizeof(void)  (x was not a constant expression)
  */
 #define __is_constexpr(x) \
 	(sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))
-- 
2.30.2


             reply	other threads:[~2022-01-31 20:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 20:43 Kees Cook [this message]
2022-01-31 21:26 ` [PATCH] linux/const.h: Explain how __is_constexpr() works Gustavo A. R. Silva
2022-02-01 12:01 ` Jani Nikula
2022-02-01 13:05 ` Rasmus Villemoes
2022-02-01 15:09   ` Matthew Wilcox
2022-02-02  8:49   ` David Laight
2022-02-02 15:43     ` Uecker, Martin
2022-02-02 20:14       ` Miguel Ojeda
2022-02-02 16:19 ` David Laight
2022-02-02 20:13   ` Miguel Ojeda
2022-02-02 22:20     ` David Laight
2022-02-02 23:01       ` Miguel Ojeda
2022-02-02 23:08         ` Nick Desaulniers
2022-02-02 20:44   ` Rasmus Villemoes
2022-02-02 22:42     ` David Laight
2022-02-03  0:28       ` Miguel Ojeda
2022-02-02 20:43 ` Miguel Ojeda
2022-02-03  9:25   ` David Laight

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=20220131204357.1133674-1-keescook@chromium.org \
    --to=keescook@chromium.org \
    --cc=Martin.Uecker@med.uni-goettingen.de \
    --cc=akpm@linux-foundation.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=gustavoars@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=mingo@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rikard.falkeborn@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.