From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nathan Chancellor <nathan@kernel.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 01:28:35 +0100 [thread overview]
Message-ID: <20250502002835.GT2023217@ZenIV> (raw)
In-Reply-To: <CAHk-=whL8rmneKbrXpccouEN1LYDtEX3L6xTr20rkn7O_XT4uw@mail.gmail.com>
On Thu, May 01, 2025 at 04:28:25PM -0700, Linus Torvalds wrote:
> On Thu, 1 May 2025 at 16:00, Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > +({ type __dummy = {}; \
> > + typeof(x) __dummy2 = {}; \
>
> I'm actually surprised that this doesn't cause warnings in itself.
>
> The types in question are not necessarily compound types, and can be
> simple types like 'int'.
>
> The fact that you can write
>
> int x = {};
>
> without the compiler screaming bloody murder about that insanity blows
> my mind, but it does seem to be valid C (*).
>
> How long has that been valid? Because this is certainly new to the
> kernel, and sparse does complain about this initializer.
>
> So honestly, this will just cause endless sparse warnings instead. I
> think disabling this warning for now is likely the right thing to do.
>
> Linus
>
> (*) Yes, the empty initializer is new in C23, but we've used that in
> the kernel for non-scalar objects for a long time.
For scalars it had been flat-out invalid all along - doesn't even
need -Wpedantic for gcc to reject that. I hadn't checked C23, but
older variants all fail on that.
We can force sparse to accept that thing, but I rather wonder if it's
a good idea. Both gcc 12 and clang 14 give hard error with -std=gnu11;
do we really want to bump the minimal versions that much?
next prev parent reply other threads:[~2025-05-02 0:28 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 [this message]
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
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=20250502002835.GT2023217@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.