[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20060724015549.c4294b05.pj@sgi.com>
Date: Mon, 24 Jul 2006 01:55:49 -0700
From: Paul Jackson <pj@....com>
To: Jan Engelhardt <jengelh@...ux01.gwdg.de>
Cc: ricknu-0@...dent.ltu.se, linux-kernel@...r.kernel.org,
akpm@...l.org, jeff@...zik.org, adobriyan@...il.com,
vlobanov@...akeasy.net, 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 4)
Jan wrote:
> Can someone please tell me what advantage 'define true true' is going to
> bring, besides than being able to '#ifdef true'?
I think Jeff's replies to this are a tad confusing. He seems
to be answering in part with the broader point of the value of
increased type checking using enums, and not focusing on the
specific reason these two defines of true and false are there.
As best as I can tell, these two odd looking defines are just to
suppress #define alternative's to our enum based false and true
constructs, in the likely case that the alternatives are guarded
with the usual #ifndef logic.
In other words, their advantage is basically what you said, being
able to '#ifdef true' (or #ifndef).
As I recommend in another subthread, these two defines need a comment.
And since there is only one "#ifndef true" left in the entire kernel
source tree, in drivers/media/video/cpia2/cpia2.h, I would think it
would be better to just remove those lines from cpia2.h, and drop
these two odd looking defines.
--
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/
Powered by blists - more mailing lists