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: <57D0391C.90305@emindsoft.com.cn>
Date:   Wed, 07 Sep 2016 23:58:20 +0800
From:   Chen Gang <chengang@...ndsoft.com.cn>
To:     Al Viro <viro@...IV.linux.org.uk>
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 9/4/16 09:01, Al Viro wrote:
> 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.
> 

Sorry for replying late, and excuse me, I did not read the details more.
During these days I have no enough time on it (working, buying house,
and catching a cold, but lucky enough that my father's health is OK).

I shall try to read the details and analyze it within next weekend (I
guess I can not finish within this week end, sorry again for I really
have no time during these days).

But all together, for me, I guess our discussion can not 'prevent' that
bool return value instead of int return value for pure bool function in
our kernel. :-)


Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.