[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1153971041.44c833619915b@portal.student.luth.se>
Date: Thu, 27 Jul 2006 05:30:41 +0200
From: ricknu-0@...dent.ltu.se
To: Paul Jackson <pj@....com>
Cc: linux-kernel@...r.kernel.org, akpm@...l.org, jeff@...zik.org,
adobriyan@...il.com, vlobanov@...akeasy.net,
jengelh@...ux01.gwdg.de, 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 6)
Citerar Paul Jackson <pj@....com>:
> Fun stuff to do in the future:
> Convert test_bit() and various other test_*() and
> atomic_*() operators to return bool.
> Convert many TRUE/FALSE to true/false, in a patch of
> similar size to Andrew's March 2006 patch entitled:
> "[patch 1/1] consolidate TRUE and FALSE".
> Convert a variety of spellings of BOOLEAN to "bool".
> Convert routines and variables using the old C
> convention of int/0/1 for boolean to the
> new bool/false/true.
> How do we detect breakage that results from converting
> an apparent boolean to these values, when the
> code actually worked by using more than just
> values 0 and 1 for the variable in question?
> How do we detect any breakage caused by possible changes
> in the sizeof variables whose type we changed?
> Various sparse and/or gcc checks that benefit from
> knowing the additional constraints on bool types.
Well... that's some work to be done :)
Will save the list and try to mark it of along the road.
> Paul Jackson <pj@....com> 1.925.600.0401
/Richard Knutsson
-
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