lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 19 Aug 2021 13:37:20 -0700
From:   Linus Torvalds <>
To:     Nathan Chancellor <>
Cc:     "Gustavo A. R. Silva" <>,
        Kees Cook <>,
        Linux Kernel Mailing List <>,
        Nick Desaulniers <>,
Subject: Re: [GIT PULL] Enable -Wimplicit-fallthrough for Clang for 5.14-rc7

On Thu, Aug 19, 2021 at 1:17 PM Nathan Chancellor <> wrote:
> For what it's worth, clang's version of -Wimplicit-fallthrough would
> have caught the bug in commit 652b44453ea9 [..]

The thing is, any warning can catch a bug. The "signed pointer"
warnings could catch things too if people really care about "unsigned
char *" vs just plain "char *".

But warnings that have too many false positives are more likely to
hide bugs than expose them. So it's very much a balancing act.

I personally think that false positives are deadly: I'd much rather
have a c completely clean build where are the warnings are big red
flags, than a build that has warnings that _may_ be signs of bugs, but
where you have known false positives that have no sane workaround.

Because with even a _single_ false positive, people will immediately
just stop caring about any other warnings at all. We've seen that over
and over again.

This is why a compiler warning - to be useful - has to be completely
unambiguously about bad code, or at least have a alternate "good code
pattern" that is no worse than the code that the warning about.

> However, if you are truly opposed to a version check, can we at least
> just check for the presence of -Wunreachable-code-fallthrough as I
> suggested before?

I'm ok with that, since at that point there are no false warnings.

But even then, it's much too late for 5.14 by now, considering that
this has had issues, and that we already enable the warnings on the
common gcc builds.


Powered by blists - more mailing lists