Date: Sun, 21 Jan 2007 14:40:47 -0500 (EST)
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: Nicholas Miell <nmiell@comcast.net>
cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>,
       Andrew Morton <akpm@osdl.org>, linville@tuxdriver.com
Subject: Re: [PATCH] Introduce simple TRUE and FALSE boolean macros.
In-Reply-To: <1169401892.2999.1.camel@entropy>
Message-ID: <Pine.LNX.4.64.0701211430020.17235@CPE00045a9c397f-CM001225dbafb6>
References: <Pine.LNX.4.64.0701210454590.2844@CPE00045a9c397f-CM001225dbafb6>
 <1169401892.2999.1.camel@entropy>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1974
Lines: 43

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/