Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-26 Thread Finn Thain
On Wed, 25 Nov 2020, Nick Desaulniers wrote: > On Wed, Nov 25, 2020 at 1:33 PM Finn Thain wrote: > > > > Or do you think that a codebase can somehow satisfy multiple checkers > > and their divergent interpretations of the language spec? > > Have we found any case

Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-26 Thread Finn Thain
On Wed, 25 Nov 2020, Nick Desaulniers wrote: > On Wed, Nov 25, 2020 at 1:33 PM Finn Thain > wrote: > > > > Or do you think that a codebase can somehow satisfy multiple checkers > > and their divergent interpretations of the language spec? > > Have we found any c

Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-26 Thread Finn Thain
On Wed, 25 Nov 2020, Nick Desaulniers wrote: > So developers and distributions using Clang can't have > -Wimplicit-fallthrough enabled because GCC is less strict (which has > been shown in this thread to lead to bugs)? We'd like to have nice > things too, you know. > Apparently the GCC

Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-25 Thread Finn Thain
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

Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-25 Thread Finn Thain
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

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-24 Thread Finn Thain
On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes t

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-24 Thread Finn Thain
On Mon, 23 Nov 2020, Joe Perches wrote: > On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote: > > it's not for me to prove that such patches don't affect code > > generation. That's for the patch author and (unfortunately) for > > reviewers. > > Ideally, t

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Finn Thain
On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > It isn't that much effort, isn't it? Plus we need to take into account > the future mistakes that it might prevent, too. We should also take into account optimisim about future improvements in tooling. > So even if there were zero problems found

Re: [RFC] MAINTAINERS tag for cleanup robot

2020-11-23 Thread Finn Thain
On Sun, 22 Nov 2020, Joe Perches wrote: > On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote: > > We can enforce sysfs_emit going forwards > > using tools like checkpatch > > It's not really possible for checkpatch to find or warn about > sysfs uses of sprintf. checkpatch is really just

Re: [RFC] clang tooling cleanups

2020-10-28 Thread Finn Thain
On Tue, 27 Oct 2020, t...@redhat.com wrote: > This rfc will describe > An upcoming treewide cleanup. > How clang tooling was used to programatically do the clean up. > Solicit opinions on how to generally use clang tooling. > This tooling is very impressive. It makes possible an idea that I