From: Al Viro <viro@zeniv.linux.org.uk>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Nicolas Schier <nicolas.schier@linux.dev>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, patches@lists.linux.dev,
stable@vger.kernel.org,
Linux Kernel Functional Testing <lkft@linaro.org>,
Marcus Seyfarth <m.seyfarth@gmail.com>
Subject: Re: [PATCH 2/2] include/linux/typecheck.h: Zero initialize dummy variables
Date: Fri, 2 May 2025 03:05:34 +0100 [thread overview]
Message-ID: <20250502020534.GU2023217@ZenIV> (raw)
In-Reply-To: <20250502012449.GA1744689@ax162>
On Thu, May 01, 2025 at 06:24:49PM -0700, Nathan Chancellor wrote:
> > How long has that been valid? Because this is certainly new to the
> > kernel, and sparse does complain about this initializer.
>
> As you noted, brace initialization for scalars appears to always be
> valid (at least in my testing) but as Al points out, empty braces for
> scalars is only supported in GCC 13+ and Clang 17+ (I think [1] was the
> clang commit), so that is not going to fly...
From some digging around it looks like
* {} for compounds had been an extension for quite a while
* C++11 got it into standard, with semantics defined as "same
value you get for static-duration variables of that type without an
explicit initializer". For scalar types as well, with the same
semantics.
* On C side that happened (again, with scalar types allowed)
in 2022; N2912 is the first draft with that change already merged,
N2913 is the corresponding editor's report, saying that change in question
(N2900) got merged in January/February virtual meeting.
IOW, C23 has it, no previous versions do. For C17 this syntax
is an error, and AFAICS you need at least -std=c2x or -std=gnu2x to have
it acceptable.
We can make sparse accept it (either unconditionally or with sufficient
-std in arguments), but that won't do a damn thing for cc(1). Does
clang (any version) really accept it with -std=gnu11?
next prev parent reply other threads:[~2025-05-02 2:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-01 23:00 [PATCH 0/2] Deal with clang's -Wdefault-const-init-unsafe Nathan Chancellor
2025-05-01 23:00 ` [PATCH 1/2] kbuild: Disable -Wdefault-const-init-field-unsafe Nathan Chancellor
2025-05-09 13:02 ` Masahiro Yamada
2025-05-01 23:00 ` [PATCH 2/2] include/linux/typecheck.h: Zero initialize dummy variables Nathan Chancellor
2025-05-01 23:28 ` Linus Torvalds
2025-05-01 23:37 ` Linus Torvalds
2025-05-02 0:28 ` Al Viro
2025-05-02 1:24 ` Nathan Chancellor
2025-05-02 1:34 ` Linus Torvalds
2025-05-02 2:09 ` Nathan Chancellor
2025-05-02 2:05 ` Al Viro [this message]
2025-05-02 2:36 ` Nathan Chancellor
2025-05-02 9:46 ` kernel test robot
-- strict thread matches above, loose matches on Subject: below --
2025-05-07 7:44 kernel test robot
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=20250502020534.GU2023217@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=justinstitt@google.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkft@linaro.org \
--cc=llvm@lists.linux.dev \
--cc=m.seyfarth@gmail.com \
--cc=masahiroy@kernel.org \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=nicolas.schier@linux.dev \
--cc=patches@lists.linux.dev \
--cc=stable@vger.kernel.org \
--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.