linux-kernel - Re: [GIT PULL] KVM fixes for Linux 5.15-rc7

lists.openwall.net		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 linux-cve-announce 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, 18 Oct 2021 07:57:36 -1000
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Jim Mattson <jmattson@...gle.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        KVM list <kvm@...r.kernel.org>
Subject: Re: [GIT PULL] KVM fixes for Linux 5.15-rc7

On Mon, Oct 18, 2021 at 7:42 AM Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> * avoid warning with -Wbitwise-instead-of-logical

Christ. Please no.

Guys, you can't just mindlessly shut off warnings without even
thinking about the code.

Apparently the compiler gives completely insane warning "fixes"
suggestions, and somebody just completely mindlessly followed that
compiler badness.

The way to do a logical "or" (instead of a bitwise one on two boolean
expressions) is to use "||".

Instead, the code was changed to completely insane

   (int) boolexpr1 | (int) boolexpr2

thing, which is entirely illegible and pointless, and no sane person
should ever write code like that.

In other words, the *proper* fix to a warning is to look at the code,
and *unsderstand* the code and the warning, instead of some mindless
conversion to just avoid a warning.

NEVER EVER do mindless changes to source code because the compiler
tells you to. Apparently the clang people wrote a particularly bad
warning "explanation", and that's on clang.

I'm not going to pull this. The clang warning fix is wrong, and then
another commit literally disables accounting for another non-fatal
run-time warning.

Again - warnings are not an excuse to just "mindlessly shut up the warning".

They need some thought.

None of this kind of "I'll do wrong things just to make the warning go
away" garbage that this pull request has two very different examples
of.

I'm adding some clang people, because apparently that

    note: cast one or both operands to int to silence this warning

thing came from clang. Somebody in the clang community really needs to
re-think their "informational" messages.

Giving people those kinds of insane suggestions is a disservice to
everybody. Clang should fix their stupid "note" before release.
Please, guys.

            Linus