Finn Thain
2020-Nov-24 22:24 UTC
[Nouveau] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Tue, 24 Nov 2020, Kees Cook wrote:> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote: > > Really, no ... something which produces no improvement has no value at > > all ... we really shouldn't be wasting maintainer time with it because > > it has a cost to merge. I'm not sure we understand where the balance > > lies in value vs cost to merge but I am confident in the zero value > > case. > > What? We can't measure how many future bugs aren't introduced because > the kernel requires explicit case flow-control statements for all new > code. >These statements are not "missing" unless you presume that code written before the latest de facto language spec was written should somehow be held to that spec. If the 'fallthrough' statement is not part of the latest draft spec then we should ask why not before we embrace it. Being that the kernel still prefers -std=gnu89 you might want to consider what has prevented -std=gnu99 or -std=gnu2x etc.> We already enable -Wimplicit-fallthrough globally, so that's not the > discussion. The issue is that Clang is (correctly) even more strict than > GCC for this, so these are the remaining ones to fix for full Clang > coverage too. >Seems to me you should be patching the compiler. When you have consensus among the language lawyers you'll have more credibility with those being subjected to enforcement.
Miguel Ojeda
2020-Nov-24 23:15 UTC
[Nouveau] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain at telegraphics.com.au> wrote:> > These statements are not "missing" unless you presume that code written > before the latest de facto language spec was written should somehow be > held to that spec.There is no "language spec" the kernel adheres to. Even if it did, kernel code is not frozen. If an improvement is found, it should be applied.> If the 'fallthrough' statement is not part of the latest draft spec then > we should ask why not before we embrace it. Being that the kernel still > prefers -std=gnu89 you might want to consider what has prevented > -std=gnu99 or -std=gnu2x etc.The C standard has nothing to do with this. We use compiler extensions of several kinds, for many years. Even discounting those extensions, the kernel is not even conforming to C due to e.g. strict aliasing. I am not sure what you are trying to argue here. But, since you insist: yes, the `fallthrough` attribute is in the current C2x draft. Cheers, Miguel
Finn Thain
2020-Nov-24 23:53 UTC
[Nouveau] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
On Wed, 25 Nov 2020, Miguel Ojeda wrote:> > The C standard has nothing to do with this. We use compiler extensions > of several kinds, for many years. Even discounting those extensions, the > kernel is not even conforming to C due to e.g. strict aliasing. I am not > sure what you are trying to argue here. >I'm saying that supporting the official language spec makes more sense than attempting to support a multitude of divergent interpretations of the spec (i.e. gcc, clang, coverity etc.) I'm also saying that the reason why we use -std=gnu89 is that existing code was written in that language, not in ad hoc languages comprised of collections of extensions that change with every release.> But, since you insist: yes, the `fallthrough` attribute is in the > current C2x draft. >Thank you for checking. I found a free version that's only 6 weeks old: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf It will be interesting to see whether 6.7.11.5 changes once the various implementations reach agreement.