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]
Message-ID: <CAHk-=wg0+bWDKfApDHVR70hsaRA_7bEZfG1XtN2DxZGo+np9Ug@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ