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:   Thu, 26 Nov 2020 16:28:12 +0100
From:   Geert Uytterhoeven <>
To:     Miguel Ojeda <>
Cc:     Edward Cree <>,
        ALSA Development Mailing List <>,,,,
        linux-wireless <>,
        Linux Fbdev development list <>,
        dri-devel <>,
        "Gustavo A. R. Silva" <>,
        James Bottomley <>,,,,
        MTD Maling List <>,,,,,,,,
        Lars Ellenberg <>,
        driverdevel <>,,,
        Nick Desaulniers <>,
        scsi <>,
        Nathan Chancellor <>,
        linux-rdma <>,,,
        linux-security-module <>,
        amd-gfx list <>,,,
        ACPI Devel Maling List <>,,,
        linux-input <>,
        Miguel Ojeda <>,
        Jakub Kicinski <>,
        Ext4 Developers List <>,
        Linux Media Mailing List <>,
        Kees Cook <>,,
        linux-arm-msm <>,
        Intel Graphics Development <>,,,,
        "open list:GPIO SUBSYSTEM" <>,,,,
        Nouveau Dev <>,,
        ceph-devel <>,,
        Linux ARM <>,,
        Linux Watchdog Mailing List <>,
        "open list:NFS, SUNRPC, AND..." <>,,,
        Linux-MM <>,
        Network Development <>,,
        Linux MMC List <>,
        linux-kernel <>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <>,
        Linux-Renesas <>,, USB list <>,
        NetFilter <>,
        Linux Crypto Mailing List <>,, Joe Perches <>,
        linux-integrity <>,
        target-devel <>,
Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang

Hi Miguel,

On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda
<> wrote:
> On Wed, Nov 25, 2020 at 11:44 PM Edward Cree <> wrote:
> > To make the intent clear, you have to first be certain that you
> >  understand the intent; otherwise by adding either a break or a
> >  fallthrough to suppress the warning you are just destroying the
> >  information that "the intent of this code is unknown".
> If you don't know what the intent of your own code is, then you
> *already* have a problem in your hands.

The maintainer is not necessarily the owner/author of the code, and
thus may not know the intent of the code.

> > or does it flag up code
> >  that can be mindlessly "fixed" (in which case the warning is
> >  worthless)?  Proponents in this thread seem to be trying to
> >  have it both ways.
> A warning is not worthless just because you can mindlessly fix it.
> There are many counterexamples, e.g. many
> checkpatch/lint/lang-format/indentation warnings, functional ones like
> the `if (a = b)` warning...

BTW, you cannot mindlessly fix the latter, as you cannot know if
"(a == b)" or "((a = b))" was intended, without understanding the code
(and the (possibly unavailable) data sheet, and the hardware, ...).

P.S. So far I've stayed out of this thread, as I like it if the compiler
     flags possible mistakes.  After all I was the one fixing new
     "may be used uninitialized" warnings thrown up by gcc-4.1, until
     (a bit later than) support for that compiler was removed...



Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists