On Tue, 2007-05-08 at 12:14 -0700, Andrew Morton wrote:
> On Tue, 08 May 2007 10:11:00 -0500
> James Bottomley <[EMAIL PROTECTED]> wrote:
> 
> > > That being said, the patch is moderately wrong (or at least incomplete)
> > > because it does things like:
> > > 
> > > -            unsigned char done = FALSE;
> > > +            unsigned char done = false;
> > > 
> > > whereas it should have done
> > > 
> > > -            unsigned char done = FALSE;
> > > +            bool done = false;
> > 
> > And the value to the driver of this transformation?
> 
> Not having to define private versions of TRUE and FALSE.  That's
> a great blinking "something is wrong here" sign.

Agree.  I would like to get rid of private versions of these.

> Obviously something like TRUE/FALSE should be a kernel-wide thing, not a
> driver-private thing.  After quite some discussion and consideration, we
> decided to stick with standard unmodified C99 (not C++) and implemented
> that in include/linux/types.h and in include/linux/stddef.h.
> 
> Now, driver authors can go off and ignore all this, but others will not.  That
> driver-private TRUE/FALSE is a big fat target saying "krufty, clean me up".

Agree ... my complaint is the use of bool in the above example and the
fact that true/false are defined in stddef.h whereas almost every driver
uses TRUE/FALSE.  I really prefer the upcased latter version which is
well understood in C circles (and the private definitions can be excised
with a lot less churn than downcasing every instance of TRUE/FALSE).
However, could we compromise and just add TRUE = true, FALSE = false to
the enum?

James


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to