[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yq0lkq4vbs3.fsf@jaguar.mkp.net>
Date: 04 Aug 2006 10:03:08 -0400
From: Jes Sorensen <jes@....com>
To: Jeff Garzik <jeff@...zik.org>
Cc: ricknu-0@...dent.ltu.se, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...l.org>
Subject: Re: [RFC][PATCH] A generic boolean
>>>>> "Jeff" == Jeff Garzik <jeff@...zik.org> writes:
Jeff> ricknu-0@...dent.ltu.se wrote:
>> A first step to a generic boolean-type. The patch just introduce
>> the bool (in
Jeff> Since gcc supports boolean types and can optimize for such,
Jeff> introducing bool is IMO a good thing.
>> -Why would we want it? -There is already some how are depending on
>> a "boolean"-type (like NTFS). Also, it will clearify functions who
>> returns a boolean from one returning a value, ex: bool it_is_ok();
>> char it_is_ok(); The first one is obvious what it is doing, the
>> secound might return some sort of status.
Jeff> A better reason is that there is intrinsic compiler support for
Jeff> booleans.
Well late to the dicussion, but I still want to point out that forcing
a boolean type of a different size upon existing kernel code is not
always a great idea and can have nasty side effects for struct
alignments. Not to mention that on some architectures, accessing a u1
is a lot slower than accessing an int. If a developer really wants to
use the smaller type he/she should do so explicitly being aware of the
impact.
The kernel is written in C, not C++ or Jave or some other broken
language and C doesn't have 'bool'. This patch falls under the
'typedefs considered evil' or typedef for the sake of typedef, if you
ask me.
Regards,
Jes
-
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