On Tue, Nov 24, 2020 at 1:58 AM Finn Thain [off-list ref] wrote:

What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

For example, "There is no way to guess what the effect would be if the
compiler trained programmers to add a knee-jerk 'break' statement to avoid
a warning".

It is only knee-jerk if you think you are infallible.

Moreover, what I meant was that preventing programmer mistakes is a
problem to be solved by development tools

This warning comes from a development tool -- the compiler.

The idea that retro-fitting new
language constructs onto mature code is somehow necessary to "prevent
future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
leads to well-intentioned patches that cause regressions, it is partly on
you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

Have you ever considered the overall cost of the countless
-Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

Perhaps you pay the power bill for a build farm that produces logs that
no-one reads? Perhaps you've run git bisect, knowing that the compiler
messages are not interesting? Or compiled software in using a language
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and
wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

No, 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.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel