linux-kernel - Re: [PATCH] Introduce simple TRUE and FALSE boolean macros.

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: <Pine.LNX.4.64.0701211430020.17235@CPE00045a9c397f-CM001225dbafb6>
Date:	Sun, 21 Jan 2007 14:40:47 -0500 (EST)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Nicholas Miell <nmiell@...cast.net>
cc:	Linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>, linville@...driver.com
Subject: Re: [PATCH] Introduce simple TRUE and FALSE boolean macros.

On Sun, 21 Jan 2007, Nicholas Miell wrote:

> On Sun, 2007-01-21 at 05:03 -0500, Robert P. J. Day wrote:
> >   Introduce the TRUE and FALSE boolean macros so that everyone can
> > stop re-inventing them, and remove the one occurrence in the
> > source tree that clashes with that change.

> If you're going to introduce true and false macros, you should
> probably use the official all-lowercase C99 version.

i'm going to try this one more time, and see if i can get my point
across.  *yes*, the *eventual* goal should be to use the official
all-lowercase C99 versions of "true" and "false", and the patch i
proposed is, in fact, the first step in getting there.

by adding (temporarily) the definitions of TRUE and FALSE to types.h,
you should then (theoretically) be able to delete over 100 instances
of those same macros being *defined* throughout the source tree.
you're not going to be deleting the hundreds and hundreds of *uses* of
TRUE and FALSE (not yet, anyway) but, at the very least, by adding two
lines to types.h, you can delete all those redundant *definitions* and
make sure that nothing breaks.  (it shouldn't, of course, but it's
always nice to be sure.)

*now*, once that's done, you can start going through the tree and
doing the conversion from upper case to lower case, little by little,
subsystem by subsystem.

the predictable response will be, "you really should do that all at
once."  that's not going to happen, and you know it, and i know it.
that kind of change would be too big, and too disruptive.  so why not
just add two macro defines, then delete over 100 lines of what are now
redundant definitions, make sure nothing breaks, then move on to phase
two.

do we understand one another now?

rday
-
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/