Received-SPF: pass (google.com: domain of linux-kernel+bounces-88058-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Kees Cook <keescook@chromium.org>, Rasmus Villemoes
 <linux@rasmusvillemoes.dk>
Cc: Kees Cook <keescook@chromium.org>, "Gustavo A . R . Silva"
 <gustavoars@kernel.org>, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
 David Laight <David.Laight@aculab.com>, Nick Desaulniers
 <ndesaulniers@google.com>, Martin Uecker
 <Martin.Uecker@med.uni-goettingen.de>, Jonathan Corbet <corbet@lwn.net>,
 linux-doc@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>,
 linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] compiler.h: Explain how __is_constexpr() works
In-Reply-To: <20240301044428.work.411-kees@kernel.org>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
References: <20240301044428.work.411-kees@kernel.org>
Date: Fri, 01 Mar 2024 10:16:47 +0200
Message-ID: <87zfvi5pu8.fsf@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

On Thu, 29 Feb 2024, Kees Cook <keescook@chromium.org> wrote:
> The __is_constexpr() macro is dark magic. Shed some light on it with
> a comment to explain how and why it works.

Hey, it was a fun little puzzle to figure out using the C standard. Now
you're ruining it for everyone! ;)

The description matches my recollection of how it works. Especially the
meaning of the first 8 threw me off way back when. And looks like I've
replied to that effect for v1.

FWIW,

Reviewed-by: Jani Nikula <jani.nikula@intel.com>

but I'm sure there are more pedantic reviewers for all the minor
details.

>
> Acked-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: David Laight <David.Laight@aculab.com>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: Martin Uecker <Martin.Uecker@med.uni-goettingen.de>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> v2: *thread necromancy* rewrite based on feedback to v1
> v1: https://lore.kernel.org/all/20220131204357.1133674-1-keescook@chromium.org/
> ---
>  include/linux/compiler.h | 39 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index bb1339c7057b..38cd9f3c8f6a 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -231,6 +231,45 @@ static inline void *offset_to_ptr(const int *off)
>   * 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() return 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 first literal "8" isn't important. It could be any literal value.
> + * - The second literal "8" is to avoid warnings about unaligned pointers;
> + *   this could otherwise just be "1".
> + * - (long)(x) is used to avoid warnings about 64-bit types on 32-bit
> + *   architectures.
> + * - The C Standard defines "null pointer constant", "(void *)0", as
> + *   distinct from other void pointers.
> + * - If (x) is an integer constant expression, then the "* 0l" resolves
> + *   it into an integer constant expression of value 0. Since it is cast to
> + *   "void *", this makes the second operand a null pointer constant.
> + * - If (x) is not an integer constant expression, then the second operand
> + *   resolves to a void pointer (but not a null pointer constant: the value
> + *   is not an integer constant 0).
> + * - The conditional operator's third operand, "(int *)8", is an object
> + *   pointer (to type "int").
> + * - The behavior (including the return type) of the conditional operator
> + *   ("operand1 ? operand2 : operand3") depends on the kind of expressions
> + *   given for the second and third operands. This is the central mechanism
> + *   of the macro:
> + *   - When one operand is a null pointer constant (i.e. when x is an integer
> + *     constant expression) and the other is an object pointer (i.e. our
> + *     third operand), the conditional operator returns the type of the
> + *     object pointer operand (i.e. "int *). Here, within the sizeof(), we
> + *     would then get:
> + *       sizeof(*((int *)(...))  == sizeof(int)  == 4
> + *   - When one operand is a void pointer (i.e. when x is not an integer
> + *     constant expression) and the other is an object pointer (i.e. our
> + *     third operand), the conditional operator returns a "void *" type.
> + *     Here, within the sizeof(), we would then get:
> + *       sizeof(*((void *)(...)) == sizeof(void) == 1
> + * - The equality comparison to "sizeof(int)" therefore depends on (x):
> + *     sizeof(int) == sizeof(int)     (x) was a constant expression
> + *     sizeof(int) != sizeof(void)    (x) was not a constant expression
>   */
>  #define __is_constexpr(x) \
>  	(sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))

-- 
Jani Nikula, Intel