[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <842506f3-6a5a-424c-90a3-ba55a4262a74@t-8ch.de>
Date: Mon, 25 Nov 2024 16:24:35 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
Nicolas Schier <nicolas@...sle.eu>, Nick Desaulniers <ndesaulniers@...gle.com>,
Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH RFC] kbuild: disable -Wc23-extensions from clang
Hi Nathan,
On 2024-11-25 08:07:00-0700, Nathan Chancellor wrote:
> On Mon, Nov 25, 2024 at 10:03:00AM +0100, Thomas Weißschuh wrote:
> > Some of the C23 extensions are also GNU extensions, which are allowed.
> > Examples are declarations after labels or function definitions with
> > omitted parameter names.
> >
> > Also with the switch to C23 at some point in the future all those
>
> We are likely a ways off from being able to switch to C23:
>
> https://lore.kernel.org/10db3077-9409-446d-8e50-1a2a803db767@app.fastmail.com/
Agreed. My reasoning is more that we know today that the constructs will
not be a problem in the future as they are allowed by the future spec.
So fixing the warnings today would only be pointless busywork.
> > warnings will be resolved automatically anyways.
> >
> > Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
> > ---
> > I had some patches failing the CI only with clang.
> > And it feels like unnecessary busywork to fix these warnings.
>
> A declaration after a label is a hard error with clang 17 and older, so
> I think it is entirely appropriate to continue to warn on that:
>
> https://godbolt.org/z/sj98GMhv3
Ack, then this RFC does not really make sense.
Thanks for the pointer.
> While a function definition with omitted parameter names is always a
> warning for the versions of clang supported by the kernel, I still think
> those should be fixed for consistency sake, as I have really only seen
> these occur in stub functions, which should match the definition of the
> full function.
In stubs or callbacks which don't need all arguments.
The prototypes themselves also fairly often don't name the parameters.
So having the stubs right next to them need the names feels
inconsistent.
But any discussion is pointless anyways right now.
>
> > ---
> > scripts/Makefile.extrawarn | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
> > index 1d13cecc7cc7808610e635ddc03476cf92b3a8c1..0da75c9d84da4daf6936495a5ab96df75658da4f 100644
> > --- a/scripts/Makefile.extrawarn
> > +++ b/scripts/Makefile.extrawarn
> > @@ -31,6 +31,8 @@ KBUILD_CFLAGS-$(CONFIG_CC_NO_ARRAY_BOUNDS) += -Wno-array-bounds
> > ifdef CONFIG_CC_IS_CLANG
> > # The kernel builds with '-std=gnu11' so use of GNU extensions is acceptable.
> > KBUILD_CFLAGS += -Wno-gnu
> > +# Some allowed GNU extensions are also C23 extensions
> > +KBUILD_CFLAGS += $(call cc-disable-warning, c23-extensions)
> > else
> >
> > # gcc inanely warns about local variables called 'main'
> >
> > ---
> > base-commit: 9f16d5e6f220661f73b36a4be1b21575651d8833
> > change-id: 20241118-kbuild-c23-extensions-2560d140de36
> >
> > Best regards,
> > --
> > Thomas Weißschuh <linux@...ssschuh.net>
> >
Powered by blists - more mailing lists