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]
Date:	Mon, 26 Jan 2015 14:32:46 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Quentin Lambert <lambert.quentin@...il.com>
Cc:	Zhang Rui <rui.zhang@...el.com>,
	Robert Moore <robert.moore@...el.com>,
	Lv Zheng <lv.zheng@...el.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Len Brown <lenb@...nel.org>, Shaohua Li <shaohua.li@...el.com>,
	linux-acpi@...r.kernel.org, devel@...ica.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] int to bool conversion

On Monday, January 26, 2015 09:30:55 AM Quentin Lambert wrote:
> Sorry for the delay in answering ....
> 
> On 22/01/2015 17:18, Rafael J. Wysocki wrote:
> > On Thursday, January 22, 2015 09:49:41 AM Quentin Lambert wrote:
> >> These patches convert local variables from int to bool when relevant.
> > And what exactly is the need for that?  Does that fix any functional problems?
> >
> >
> It doesn't fix any functional problem. The point of this patch
> is to increase the code readability by lifting some of the ambiguities
> that appear when using an integer variable as boolean.
> 
> My understanding is that by explicitly using a boolean declaration
> when it is relevant it clearly informs the reader that the variable
> is going to represent a binary state. Moreover, using the keywords
> true and false help indicate that the variable will not be involved
> in any computation other than boolean arithmetic.

Well, in the new code, yes.  The existing code is a different matter though
and it doesn't actually hurt if you leave the ints where they are, so there's
no reason to make those changes.

If you change old code and the change is not trivial (eg. fixes of white space
or comments, or kernel messages etc.) and someone enounters a bug that may be
related to it, they will have to go through your changes to see if that's not
the source of the bug.  That's not really productive.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ