From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755424AbdCGKy0 (ORCPT ); Tue, 7 Mar 2017 05:54:26 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35416 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754918AbdCGKyK (ORCPT ); Tue, 7 Mar 2017 05:54:10 -0500 Date: Tue, 7 Mar 2017 10:01:44 +0100 From: Ingo Molnar To: Thomas Gleixner Cc: kbuild test robot , Rik van Riel , kbuild-all@01.org, LKML , tipbuild@zytor.com, "H. Peter Anvin" , x86@kernel.org, Dave Hansen , Yu-cheng Yu , Fenghua Yu , Borislav Petkov , Peter Zijlstra , Linus Torvalds , Andrew Morton Subject: Re: [PATCH] x86/fpu: fix boolreturn.cocci warnings Message-ID: <20170307090144.GB6946@gmail.com> References: <201703060848.Q2LHSMc4%fengguang.wu@intel.com> <20170306004553.GA25764@lkp-wsm-ep1> <20170307072322.GB29708@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (Linus and Andrew Cc:-ed) * Thomas Gleixner wrote: > On Tue, 7 Mar 2017, Ingo Molnar wrote: > > > > * kbuild test robot wrote: > > > > > arch/x86/kernel/fpu/xstate.c:931:9-10: WARNING: return of 0/1 in function 'xfeatures_mxcsr_quirk' with return type bool > > > > > > Return statements in functions returning bool should use > > > true/false instead of 1/0. > > > > Note that this is a totally bogus warning. I personally find a 0/1 return more > > readable than a textual 'true/false', even if bools are used, and nowhere does the > > kernel mandate the use of 0/1. > > I disagree. > > The fact that booleans have been brought retroactively into the C-Standard > does and for compability reasons C still follows the approach "Boolean > values are just integers" does not make it any better. > > We had stupid bugs, where people returned -EINVAL from a boolean function > and introduced silly and hard to understand bugs. But this function is not using -EINVAL, it's using 0 and 1 which is both correct and unambiguous! I mean, if the Cocci script warned about -EINVAL then it would have found a clear bug. Now it's warning about the use of 0/1 literals with bool types which is perfectly legal, readable, clear C code! > The canonical values assigned to booleans are 'true' and 'false' and not > whatever people prefer. Can we please be consistent on that? I think that's backwards, because 1/0 is just as canonical for true/false, and to me personally it's in fact easier to read as well. I would really like higher level buy-in for that principle (I've Cc:-ed Linus and Andrew), and if indeed the consensus is that '0/1' cannot be used with 'bool' then I'll remove all uses of 'bool' from my patches and from code I care about and use 'int' instead. Please update Documentation/CodingStyle accordingly as well. To me a lexical 'true/false' instead of '1/0' is a step backwards in readability in many cases - using the slightly wider 'int' type is the lesser evil. Thanks, Ingo