[PATCH 000/141] Fix fall-through warnings for Clang
Miguel Ojeda
miguel.ojeda.sandonis at gmail.com
Mon Nov 23 09:05:31 EST 2020
On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain at telegraphics.com.au> 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
error).
> 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.
Cheers,
Miguel
More information about the Linux-mediatek
mailing list