[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240321183006.GA2907026@dev-arch.thelio-3990X>
Date: Thu, 21 Mar 2024 11:30:06 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev
Subject: Re: [GIT PULL] Char/Misc driver changes for 6.9-rc1
On Thu, Mar 21, 2024 at 11:10:22AM -0700, Linus Torvalds wrote:
> On Thu, 21 Mar 2024 at 06:48, Nathan Chancellor <nathan@...nel.org> wrote:
> >
> > That build warning actually happens with clang, not GCC as far as I am
> > aware, and it is actually a hard build error with older versions of
> > clang
>
> So the "labels without a statement" thing is not only a long-time gcc
> behavior (admittedly due to a parsing bug), afaik it's becoming
> "standard C" in C23.
Right, N2508 has been applied to the C23 draft [1] as far as I can tell
and clang finished implementing it with [2], which was released in
18.1.0.
> Does clang have a flag to allow this?
As far as I understand it, clang does not have separate flags to control
the warnings that it emits for the various c23 extensions that it allows
in older standard versions, just the big hammer of -Wc23-extensions.
Since GCC does not appear emit warnings for newer C features that it
allows even with older 'gnu' standard values by default (I think it does
with '-pedantic'?), perhaps we should just disable -Wc23-extensions
altogether? Not sure how big of a hammer this is, I think this type of
warning is the only thing I have seen come from -Wc23-extensions...
> Considering that gcc doesn't warn for it, and that it will become
> official at some point anyway, I think this might be a thing that we
> might be better off just accepting, rather than be in the situation
> where people write code that compiles fine with gcc and don't notice
> that clang will error out.
>
> So yes, clang is being correct, but in this case it only causes problems.
Agreed, it isn't the first time :/
[1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf
[2]: https://github.com/llvm/llvm-project/commit/8bd06d5b65845e5e01dd899a2deb773580460b89
Cheers,
Nathan
Powered by blists - more mailing lists