linux-kernel - Re: cmsg newgroup alt.sex.fetish.bool (was Re: [PATCH] arch: all: include: asm: bitops: Use bool instead of int for all bit test functions)

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: <20160904010144.GD2356@ZenIV.linux.org.uk>
Date:   Sun, 4 Sep 2016 02:01:44 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Chen Gang <chengang@...ndsoft.com.cn>
Cc:     Vineet Gupta <Vineet.Gupta1@...opsys.com>,
        Arnd Bergmann <arnd@...db.de>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "minchan@...nel.org" <minchan@...nel.org>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "gi-oh.kim@...fitbricks.com" <gi-oh.kim@...fitbricks.com>,
        "iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
        "hillf.zj@...baba-inc.com" <hillf.zj@...baba-inc.com>,
        "mgorman@...hsingularity.net" <mgorman@...hsingularity.net>,
        "mhocko@...e.com" <mhocko@...e.com>,
        "rientjes@...gle.com" <rientjes@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "rth@...ddle.net" <rth@...ddle.net>,
        "ink@...assic.park.msu.ru" <ink@...assic.park.msu.ru>,
        "mattst88@...il.com" <mattst88@...il.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will.deacon@....com" <will.deacon@....com>,
        "hskinnemoen@...il.com" <hskinnemoen@...il.com>,
        "egtvedt@...fundet.no" <egtvedt@...fundet.no>,
        "realmz6@...il.com" <realmz6@...il.com>,
        "ysato@...rs.sourceforge.jp" <ysato@...rs.sourceforge.jp>,
        "rkuo@...eaurora.org" <rkuo@...eaurora.org>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "fenghua.yu@...el.com" <fenghua.yu@...el.com>,
        "geert@...ux-m68k.org" <geert@...ux-m68k.org>,
        "james.hogan@...tec.com" <james.hogan@...tec.com>,
        "ralf@...ux-mips.org" <ralf@...ux-mips.org>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "deller@....de" <deller@....de>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>,
        "paulus@...ba.org" <paulus@...ba.org>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>,
        "schwidefsky@...ibm.com" <schwidefsky@...ibm.com>,
        "heiko.carstens@...ibm.com" <heiko.carstens@...ibm.com>,
        "dalias@...c.org" <dalias@...c.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: cmsg newgroup alt.sex.fetish.bool (was Re: [PATCH] arch: all:
 include: asm: bitops: Use bool instead of int for all bit test functions)

On Sun, Sep 04, 2016 at 06:36:56AM +0800, Chen Gang wrote:

> And for all: shall I provide the proof for another archs?
> 
> For me, Boolean gives additional chance to compiler to improve the code.

Whereas for compiler it gives nothing.  Not in those cases.

> If the compiler can not improve the code, it can treat it as int simply.
> So theoretically, at least, Boolean should not be worse than int.

Except for pointless code churn and pandering to irrational beliefs, that is...
Please, RTFISO9899 and learn the semantics of _Bool; it's not that complicated.
Start with 6.2.5[2,6] and 6.3.1.2, then look through 6.8.4 and 6.8.5 to
figure out the semantics of conditions in if/while/for.  Note also 6.5.8,
6.5.9, 6.5.13 and 6.5.14 and observe that type of (x > 5 && y < 1) is *NOT* 
_Bool; it's int.

If you can show any improvement or loss in code generation in this case
(static inline int converted to static inline bool), I would really like to
see the details.  As in .config/file/function/gcc version/target architecture.
Optimizer bugs happens, but they should be reported when found, and I would
expect _Bool handling to be _less_ exercised than that of normal logical
expressions, so loss is probably more likely.  And yes, it also should be
reported.