It would be useful to take a definitive stand on whether or not operations on two adjacent bool values are atomic with respect to one another. E.g. back in the days of the DEC Alpha, there existed no instructions that could modify the value of one bool in a word without potentially interfering in other uses of a differnt bool in the same word. That consideration does not apply to either of the current Solaris platforms. But are we introducing a constraint that Solaris could never be ported to such a platform? Or are we introducing a constraint that any values that should be updatable atomically should be stored in a boolean_t and not in a bool? Or does the compiler guarantee to allocate bools on word boundaries in platforms such as this? Either way, we should spell it out.
Peter On 08/10/09 19:35, Garrett D'Amore - sun microsystems wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > sys/stdbool.h > 1.2. Name of Document Author/Supplier: > Author: Garrett D'Amore > 1.3 Date of This Document: > 10 August, 2009 > 4. Technical Description > I am sponsoring this fast track for Roland Mainz. The case times out in one > week (8/19/2009), and minor binding is requested. > > -- Garrett > > 1. Introduction > > This case a new header <sys/stdbool.h> to allow kernel code > to use the C99 datatype "bool" and the associated values > "true" and "false". > > The committment level of these interfaces is "Committed". > > The release binding is "minor". > > 2. Discussion > > We need to move <stdbool.h> to <sys/stdbool.h> (and create a new > <stdbool.h> which sources <sys/stdbool.h>) that (new [2]) kernel > code can use the new C99 datatype "bool" ([1]) ? > > [1]="bool" differs from the traditional kernel-land "boolean_t" > datatype that it is smaller (e.g. |sizeof(boolean_t)==sizeof(int)| > vs. |sizeof(bool)==1|) and optionally allows the compiler to do > better optimisations on this datatype (since it is allowed to > assume that it only contains "true" and "false" as values instead > of the full range from |INT_MIN|-|INT_MAX| for "boolean_t" (since > this |enum| is treated as |int| by value-range optimisations)) > and usually reduces the size of executables (see CR #6870093). > > [2]=Note that we do not intend do force developers to replace > "boolean_t" in existing code, only allow that new code or changes > (optionally) can use this C99 feature. > > 3. Interface table > > Interface | committment level > -----------------------------------------------+------------------ > <sys/stdbool.h> | Commited > C99 datatype "bool" | Commited > C99 value "true" | Commited > C99 value "false" | Commited > C99 CPP symbol "__bool_true_false_are_defined" | Commited > > Notes: > 1. <sys/stdbool.h> precisely implements the functionality for > <stdbool.h> defined in IEEE Std 1003.1-2001. > 2. The ability to undefine and redefine the macros "bool", > "true", and "false" is an _implementation_detail_ in the ISO C > standard which may be withdrawn in a future version of the > standards specifications, kernel code shall _not_ rely on this > _implementation_detail_ (e.g. "#undef true", "#undef false", > "#undef bool" are not allowed in kernel code as they may cause > problems with future compiler versions). > > 4. References > - Bugster CR #6870093 RFE: C99 <stdbool.h> should be visible for > kernel modules > - IEEE Std 1003.1-2001 > - http://en.wikipedia.org/wiki/Stdbool.h > - ISO C99 draft (final document is not available for free) > http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf > > 5. Manual page differences > > None required. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > >
