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] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 Nov 2020 15:05:31 +0100
From:   Miguel Ojeda <>
To:     Finn Thain <>
Cc:     James Bottomley <>,
        Kees Cook <>,
        Jakub Kicinski <>,
        "Gustavo A. R. Silva" <>,
        linux-kernel <>,,,,,,,,,,,,,,,,,,,
        Linux ARM <>,,,,,,
        Linux Crypto Mailing List <>,,
        Ext4 Developers List <>,,,,,,,,,
        linux-input <>,,,
        Linux Media Mailing List <>,, Linux-MM <>,,,,,,,,,,,
        linux-wireless <>,
        Network Development <>,,,,,,,,,,,,,,,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <>,,,
        Nick Desaulniers <>,
        Nathan Chancellor <>,
        Miguel Ojeda <>, Joe Perches <>
Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <> wrote:
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard

> But what we inevitably get is changes like this:
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.


Powered by blists - more mailing lists