Peter Cudhea wrote:
> 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.
[snip]
> > 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
[snip]
>
> 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.
AFAIK Solaris supports |atomic_swap_uchar()| for userland applications -
since |bool| is a byte ([1]) on Solaris this may be used for atomic
operations...
[1]=Assuming the compiler cannot "reduce" it somehow further, e.g. if
the variable is "standalone" (e.g. not part of a struct, not accessed
via pointer etc.) the compiler may tweak it as it likes it (the only
other factor is the amount of states the variable may hold - but that's
exactly defined to be two ({ |true, |false| }) and therefore eliminates
that issue for the compiler).
> 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.
Erm... this case is only to make the C99 header |stdbool.h> (and the
associated C99 datatype |bool|) available for kernel code (which IMO
should've been done at the time when C99 support was added to Solaris
(e.g. this case is basically "janitor work")) and _not_ to interpret
more on top of it, e.g. we only gurantee what the ISO C standard says
about |bool| and nothing beyond that.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
