Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1336781pxb; Wed, 2 Feb 2022 02:37:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJy9a5IcMWl9/cd2YmdeJ176Ex2Ri1wWvgtsXApS77m+O9UkGY4pqdj25cuR5EvuWPtjmaMv X-Received: by 2002:a63:474c:: with SMTP id w12mr6862576pgk.147.1643798220421; Wed, 02 Feb 2022 02:37:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643798220; cv=none; d=google.com; s=arc-20160816; b=q3Ymx7/g3ZJeHOPoZZ5DDjBJbz83btLt2enHgQPS0dnJ0tlBJDyv2Jyi67SsCapYwH 9GZJ+e5faCmhy+xTvHzFWNzPN4hD/ftZhrNNE0UbCSbYGPl/bImDgsoj6l8DYihoAeL/ Jtpc5tRdicGNNesPAXOQsiTmnz8G7Xb4xfDP+0X2NZeifSTmLIxFiob9r9ZyjQW68OE7 TtDxHqFxzfXHQvSAXiqb4OYqefvmieT0mf5cQvR0BgodLFIToaqtkomtFpsbkz2CIeDD eZGNLdznXmCLF4WA1YP3wfFqoL2cjj/4KQJDG1z50WPCEL0f3osMCYBTvjJIEiEgdh6n cRXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :organization:in-reply-to:subject:cc:to:from:dkim-signature; bh=lFoEoQY5FIv/7RjOZWZXLFOl0kWiQ469wcwfbA6Lf9k=; b=vBCv9YCXqlbvKWvO0d6i2jT9praytVMWanw9QLGkNkUeiSAmTsosKdM5IONIvrLt4a 4jCRyqM3S71JJqsptUlhnU37xWf4IUVueo5AzqmnmC+D4ZXTif4yss7k5yrvureMVQEn mui11ncPMUCuA69PQ491Jm3/LJ2aw5ffoDJhSvWO9Ovo9+O584zSnx9sGzUwqzB3UwLg 89yBCOI4usKsXG2xlpclLrI9mkv+0+0aeCYH/CecDXqrng812PJSzh/kfq6+ByjuqZqr FP/yTig3PUxTANKv6mwqasznkLDP6ZDQtBZrIHotTbqStMEwHevZ/tX34G3FVCawPiCf WaOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=X5kHoSuj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i4si18952816pgj.317.2022.02.02.02.36.48; Wed, 02 Feb 2022 02:37:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=X5kHoSuj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237530AbiBAMBf (ORCPT + 99 others); Tue, 1 Feb 2022 07:01:35 -0500 Received: from mga09.intel.com ([134.134.136.24]:25834 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237302AbiBAMBe (ORCPT ); Tue, 1 Feb 2022 07:01:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643716894; x=1675252894; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=xK2CPhJ2c7fDqeNTYNEdi9CV6bv+gk4dlygHqA4TWpQ=; b=X5kHoSuj6Qpy4XZHj2DMOyq6w4z0kARlL+xHFenNpIDX3tj2aQMYbMdg ntveatj1gXdxlGuMm1iS2RC7mheX8riX6QcCBpgI7I/1Orz4hSBuZKmBF kMukqZHvqnKdivxWtj/bayuntZqoN9/STPYwecl43ih5rN+v/R1M7h9Lh 0H0Z2MrSM7WiIfbH7zj4aYmCxfI7LHfCSIjRMN0xDluFgzK1TyJ7qltKq DpRtn+z5UWTe1vU3jOq0IwD9pAbqIs7/8I28y1pzH/5oQMqkohd0QEzsy NHT8PI7ACU7Ka2aREGW/G+TZlx/7nY7X1hEdGieZfNz9mUZ9PeU4Cs202 A==; X-IronPort-AV: E=McAfee;i="6200,9189,10244"; a="247446257" X-IronPort-AV: E=Sophos;i="5.88,333,1635231600"; d="scan'208";a="247446257" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Feb 2022 04:01:32 -0800 X-IronPort-AV: E=Sophos;i="5.88,333,1635231600"; d="scan'208";a="523030836" Received: from ehanosko-mobl.ger.corp.intel.com (HELO localhost) ([10.252.6.3]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Feb 2022 04:01:26 -0800 From: Jani Nikula To: Kees Cook , Jonathan Corbet Cc: Kees Cook , Linus Torvalds , Martin Uecker , Ingo Molnar , Miguel Ojeda , Rikard Falkeborn , Arnd Bergmann , linux-doc@vger.kernel.org, Tetsuo Handa , Andrew Morton , Andy Shevchenko , Nick Desaulniers , "Gustavo A. R. Silva" , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] linux/const.h: Explain how __is_constexpr() works In-Reply-To: <20220131204357.1133674-1-keescook@chromium.org> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20220131204357.1133674-1-keescook@chromium.org> Date: Tue, 01 Feb 2022 14:01:24 +0200 Message-ID: <871r0mvlrf.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 31 Jan 2022, Kees Cook wrote: > 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 > Cc: Linus Torvalds > Cc: Martin Uecker > Cc: Ingo Molnar > Cc: Miguel Ojeda > Cc: Rikard Falkeborn > Cc: Arnd Bergmann > Cc: linux-doc@vger.kernel.org > Signed-off-by: Kees Cook > --- > 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 > + * > + * 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. I thought the first literal 8 was just for looks, and it mattered only for the last literal 8. It's been a while when I looked all of this up, but this pretty much matches what I remember. LGTM. BR, Jani. > + * - (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))) -- Jani Nikula, Intel Open Source Graphics Center