lkml.org 
[lkml]   [2020]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 000/141] Fix fall-through warnings for Clang
    On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> 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

    \
     
     \ /
      Last update: 2020-11-25 00:50    [W:4.099 / U:0.692 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site