From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162566AbcEaCG3 (ORCPT ); Mon, 30 May 2016 22:06:29 -0400 Received: from out1134-219.mail.aliyun.com ([42.120.134.219]:42216 "EHLO out1134-219.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161746AbcEaCG2 (ORCPT ); Mon, 30 May 2016 22:06:28 -0400 X-Alimail-AntiSpam: AC=CONTINUE;BC=0.07838663|-1;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03275;MF=chengang@emindsoft.com.cn;NM=1;PH=DS;RN=12;RT=12;SR=0;TI=SMTPD_----4s8kNLN_1464660373; Subject: Re: [PATCH trivial] include/linux/memblock.h: Clean up code for several trivial details To: Joe Perches , akpm@linux-foundation.org, trivial@kernel.org References: <1464532567-6353-1-git-send-email-chengang@emindsoft.com.cn> <1464534527.14627.9.camel@perches.com> <574C4C4F.8080609@emindsoft.com.cn> <1464618832.14627.23.camel@perches.com> Cc: kuleshovmail@gmail.com, tony.luck@intel.com, tangchen@cn.fujitsu.com, will.deacon@arm.com, holt@sgi.com, ard.biesheuvel@linaro.org, kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org, Chen Gang From: Chen Gang Message-ID: <574CF195.60803@emindsoft.com.cn> Date: Tue, 31 May 2016 10:06:13 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1464618832.14627.23.camel@perches.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016年05月30日 22:33, Joe Perches wrote: > On Mon, 2016-05-30 at 22:21 +0800, Chen Gang wrote: >> No, they are not necessary. But for me, it will be more clearer, since >> in our kernel (at least in include/linux/), almost all Boolean functions >> use Boolean value or expression for return (and "!!" are often used). > > Opinions vary. > > There seem to be fewer than 20 !! uses in bool return > functions in include/linux/ > ide.h:854 mlx4/driver.h:76 mlx5/device.h:744 mmzone.h:793 mtd/mtd.h:412 nilfs2_fs.h:568 nilfs2_fs.h:602 nilfs2_fs.h:667 nilfs2_fs.h:771 page-flags.h:711 pagemap.h:54 For me, we can change the related functions to Boolean functions directly. > Finding the quantity of bool conversions in include/linux > from something other than 0, 1, true, or false to 0 or 1 > is not trivial, but it is non-zero and seems rather more > than 20. > [root@localhost linux]# grep -rn "\" * | grep ' & ' | grep -v "==" | grep -v '||' | grep -v 'struct' | grep -v '!=' | grep -v ',' | grep -v '?' | grep -v '!' | grep -v '&&' | wc -l 259 After give a glance, more than 60% are not for bool functions (so I guess about 100 area hint). But I guess, quite a few of none Boolean functions above can be changed to Boolean functions, too (but have to read more code). So I guess, about 200+ matches the hint (not use "!!" for & operation in Boolean functions) in the 1000+ Boolean functions in include/linux. All together, for me: The return statement is much special than normal statements: - It is related with function's type (non-return function, Boolean function, or normal function), not only related with type cast within the statement itself. - Even for normal function, the type cast in return statement is also better: when reading source code, return statements have much more chances to be read than the function return type. - For finding Boolean function in existing normal functions, we often read the return value to know about whether it is a Boolean function or not. So, I still suggest to add type cast explicitly in return statement. Welcome any ideas, suggestions, and completions. Thanks. -- Chen Gang (陈刚) Managing Natural Environments is the Duty of Human Beings.