From: Jakub Jelinek <jakub@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: linux-toolchains@vger.kernel.org
Subject: [PATCH] include/linux: Adjust headers for C23
Date: Mon, 20 Jan 2025 13:00:46 +0100 [thread overview]
Message-ID: <Z4467umXR2PZ0M1H@tucnak> (raw)
GCC 15 changed default from -std=gnu17 to -std=gnu23. In C23
among many other changes bool, false and true are keywords
(like in C++), so defining those using typedef or enum is invalid.
The following patch adjusts the include/linux/ headers to be C23
compatible. _Bool and the C23 bool are ABI compatible, false/true
have the same values but different types (previously in the kernel
case it was an anonymous enum, in C23 it is bool), so if something uses
say sizeof(false) or typeof(true), those do change, but I doubt that
is used anywhere in the kernel.
The last change is about va_start. In C23 ellipsis can be specified
without any arguments before it, like
int foo(...)
{
va_list ap;
va_start(ap);
int ret = va_arg(ap, int);
va_end(ap);
return ret;
}
and unlike in C17 and earlier, va_start is macro with variable argument
count. Normally one should use it with just one argument or for backwards
compatibility with C17 and earlier with two arguments, second being the last
named argument. Of course, if there is no last named argument, only the
single argument va_start is an option. The stdarg.h change attempts to be
compatible with older versions of GCC and with clang as well. Both GCC 13-14
and recent versions of clang define va_start for C23 as
#define va_start(v, ...) __builtin_va_start(v, 0)
The problem with that definition is that it doesn't emit warnings when one
uses complete nonsense in there (e.g. va_start(ap, 8) or
va_start(ap, +-*, /, 3, 4.0)), so for GCC 15 it uses a different builtin
which takes care about warnings for unexpected va_start uses (as suggested
by the C23 standard). Hopefully clang will one day implement that too.
Anyway, without these changes, kernel could detect compiler defaulting to
C23 and use say -std=gnu17 option instead, but even in that case IMHO this
patch doesn't hurt.
Signed-off-by: Jakub Jelinek <jakub@redhat.com>
---
include/linux/types.h | 2 ++
include/linux/stddef.h | 2 ++
include/linux/stdarg.h | 10 ++++++++++
3 files changed, 14 insertions(+)
diff --git a/include/linux/types.h b/include/linux/types.h
index 2d7b9ae8714c..f62dca96c7f1 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -32,7 +32,9 @@ typedef __kernel_timer_t timer_t;
typedef __kernel_clockid_t clockid_t;
typedef __kernel_mqd_t mqd_t;
+#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
typedef _Bool bool;
+#endif
typedef __kernel_uid32_t uid_t;
typedef __kernel_gid32_t gid_t;
diff --git a/include/linux/stddef.h b/include/linux/stddef.h
index 929d67710cc5..16508c74fca9 100644
--- a/include/linux/stddef.h
+++ b/include/linux/stddef.h
@@ -7,10 +7,12 @@
#undef NULL
#define NULL ((void *)0)
+#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L
enum {
false = 0,
true = 1
};
+#endif
#undef offsetof
#define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER)
diff --git a/include/linux/stdarg.h b/include/linux/stdarg.h
index c8dc7f4f390c..038214722c6e 100644
--- a/include/linux/stdarg.h
+++ b/include/linux/stdarg.h
@@ -3,7 +3,17 @@
#define _LINUX_STDARG_H
typedef __builtin_va_list va_list;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ > 201710L
+#define va_start(v, ...) __builtin_va_start(v, 0)
+#ifdef __has_builtin
+#if __has_builtin(__builtin_c23_va_start)
+#undef va_start
+#define va_start(...) __builtin_c23_va_start(__VA_ARGS__)
+#endif
+#endif
+#else
#define va_start(v, l) __builtin_va_start(v, l)
+#endif
#define va_end(v) __builtin_va_end(v)
#define va_arg(v, T) __builtin_va_arg(v, T)
#define va_copy(d, s) __builtin_va_copy(d, s)
next reply other threads:[~2025-01-20 12:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-20 12:00 Jakub Jelinek [this message]
2025-01-20 18:20 ` [PATCH] include/linux: Adjust headers for C23 Nathan Chancellor
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=Z4467umXR2PZ0M1H@tucnak \
--to=jakub@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.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 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 NNTP newsgroup(s).