[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1169479123.15483.42.camel@Homer.simpson.net>
Date: Mon, 22 Jan 2007 16:18:43 +0100
From: Mike Galbraith <efault@....de>
To: "Robert P. J. Day" <rpjday@...dspring.com>
Cc: Nick Piggin <nickpiggin@...oo.com.au>,
Nicholas Miell <nmiell@...cast.net>,
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 Mon, 2007-01-22 at 06:02 -0500, Robert P. J. Day wrote:
> On Mon, 22 Jan 2007, Nick Piggin wrote:
>
> > Robert P. J. Day wrote:
> >
> > > 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.)
> >
> > Doesn't seem very worthwhile, and it legitimises this definition
> > we're trying to get rid of.
>
> hmmmmmmmm ... apparently, you totally missed my use of the important
> word "temporarily":
>
> $ grep -r "temporary hack" . | wc -l
> 16
That's a pretty good argument _against_ adding another one :) I wonder
how old those "temporary hacks" are (the ones you missed as well).
To make TRUE/FALSE go away, you or someone will have to visit them all,
which will take time. Why add an intermediate step where you or others
can end up getting interrupted (indefinitely), leaving the "temporary"
definition lying around for folks to use?
-Mike
-
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