[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250720065045.2859105-2-hpa@zytor.com>
Date: Sat, 19 Jul 2025 23:50:38 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To:
Cc: "H. Peter Anvin" <hpa@...or.com>,
Eugenio Pérez <eperezma@...hat.com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>, Alexei Starovoitov <ast@...nel.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Andrii Nakryiko <andrii@...nel.org>, Arnd Bergmann <arnd@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Dan Williams <dan.j.williams@...el.com>,
Daniel Borkmann <daniel@...earbox.net>,
Dave Hansen <dave.hansen@...ux.intel.com>,
David Laight <David.Laight@...LAB.COM>,
David Lechner <dlechner@...libre.com>,
Dinh Nguyen <dinguyen@...nel.org>,
Eduard Zingerman <eddyz87@...il.com>,
Gatlin Newhouse <gatlin.newhouse@...il.com>,
Hao Luo <haoluo@...gle.com>, Ingo Molnar <mingo@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jakub Sitnicki <jakub@...udflare.com>,
Jan Hendrik Farr <kernel@...rr.cc>, Jason Wang <jasowang@...hat.com>,
Jiri Olsa <jolsa@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Josh Poimboeuf <jpoimboe@...nel.org>, KP Singh <kpsingh@...nel.org>,
Kees Cook <kees@...nel.org>,
Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
Marc Herbert <Marc.Herbert@...ux.intel.com>,
Martin KaFai Lau <martin.lau@...ux.dev>,
Mateusz Guzik <mjguzik@...il.com>, Michal Luczaj <mhal@...x.co>,
Miguel Ojeda <ojeda@...nel.org>, Mykola Lysenko <mykolal@...com>,
NeilBrown <neil@...wn.name>, Peter Zijlstra <peterz@...radead.org>,
Przemek Kitszel <przemyslaw.kitszel@...el.com>,
Sami Tolvanen <samitolvanen@...gle.com>, Shuah Khan <shuah@...nel.org>,
Song Liu <song@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
Thomas Gleixner <tglx@...utronix.de>,
Thorsten Blum <thorsten.blum@...ux.dev>,
Uros Bizjak <ubizjak@...il.com>,
Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
Yafang Shao <laoar.shao@...il.com>, Ye Bin <yebin10@...wei.com>,
Yonghong Song <yonghong.song@...ux.dev>,
Yufeng Wang <wangyufeng@...inos.cn>, bpf@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-sparse@...r.kernel.org,
virtualization@...ts.linux.dev, x86@...nel.org
Subject: [PATCH v2 1/7] compiler_types.h: add "auto" as a macro for "__auto_type"
"auto" was defined as a keyword back in the K&R days, but as a storage
type specifier. No one ever used it, since it was and is the default
storage type for local variables.
C++11 recycled the keyword to allow a type to be declared based on the
type of an initializer. This was finally adopted into standard C in
C23.
gcc and clang provide the "__auto_type" alias keyword as an extension
for pre-C23, however, there is no reason to pollute the bulk of the
source base with this temporary keyword; instead define "auto" as a
macro unless the compiler is running in C23+ mode.
This macro is added in <linux/compiler_types.h> because that header is
included in some of the tools headers, wheres <linux/compiler.h> is
not as it has a bunch of very kernel-specific things in it.
Signed-off-by: H. Peter Anvin (Intel) <hpa@...or.com>
---
include/linux/compiler_types.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 2b77d12e07b2..c8b1ee37934e 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -13,6 +13,19 @@
#ifndef __ASSEMBLY__
+/*
+ * C23 introduces "auto" as a standard way to define type-inferred
+ * variables, but "auto" has been a (useless) keyword even since K&R C,
+ * so it has always been "namespace reserved."
+ *
+ * Until at some future time we require C23 support, we need the gcc
+ * extension __auto_type, but there is no reason to put that elsewhere
+ * in the source code.
+ */
+#if __STDC_VERSION__ < 202311L
+# define auto __auto_type
+#endif
+
/*
* Skipped when running bindgen due to a libclang issue;
* see https://github.com/rust-lang/rust-bindgen/issues/2244.
--
2.50.1
Powered by blists - more mailing lists