linux-kernel - Re: [RFC][PATCH] A generic boolean (version 6)

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: <20060726180622.63be9e55.pj@sgi.com>
Date:	Wed, 26 Jul 2006 18:06:22 -0700
From:	Paul Jackson <pj@....com>
To:	ricknu-0@...dent.ltu.se
Cc:	linux-kernel@...r.kernel.org, akpm@...l.org, jeff@...zik.org,
	adobriyan@...il.com, vlobanov@...akeasy.net,
	jengelh@...ux01.gwdg.de, getshorty_@...mail.com,
	pwil3058@...pond.net.au, mb@...sch.de, penberg@...helsinki.fi,
	stefanr@...6.in-berlin.de, larsbj@...lik.net
Subject: Re: [RFC][PATCH] A generic boolean (version 6)

Richard wrote:
> * removed the #undef false/true and #define false/true

Good - thanks.

+enum {
+	false	= 0,
+	true	= 1
+};

My inclination would have been to write this as the more terse:

+enum { false, true };

But I suspect yours is better, as some readers would not be
confident that the terse form made false == 0 and true == 1.

> a real patch (hoping for inclusion) tomorrow.

Good.

I'm delighted that this favors "true, false and bool",
over "TRUE, FALSE and various spellings of BOOLEAN".

Fun stuff to do in the future:
  Convert test_bit() and various other test_*() and
	atomic_*() operators to return bool.
  Convert many TRUE/FALSE to true/false, in a patch of
	similar size to Andrew's March 2006 patch entitled:
	"[patch 1/1] consolidate TRUE and FALSE".
  Convert a variety of spellings of BOOLEAN to "bool".
  Convert routines and variables using the old C
	convention of int/0/1 for boolean to the
	new bool/false/true.
  How do we detect breakage that results from converting
	an apparent boolean to these values, when the
	code actually worked by using more than just
	values 0 and 1 for the variable in question?
  How do we detect any breakage caused by possible changes
	in the sizeof variables whose type we changed?
  Various sparse and/or gcc checks that benefit from
	knowing the additional constraints on bool types.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.925.600.0401
-
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/