Use of bool / stdbool.h in kernel

[John Baldwin]

On Sunday, December 04, 2011 11:49:08 am mdf at freebsd.org wrote:
> On Wed, Nov 30, 2011 at 7:32 AM, John Baldwin <jhb at freebsd.org> wrote:
> > On Wednesday, November 30, 2011 12:13:53 am Bruce Evans wrote:
> >> On Tue, 29 Nov 2011 mdf at freebsd.org wrote:
> >>
> >> > At $WORK we have a hack in one of the *.mk files to allow including
> >> > stdbool.h in the kernel and we use it extensively.  This is not
> >> > allowed by style(9), as far as I can tell, because the file is in
> >> > include/stdbool.h and those files are not allowed to be included in
> >> > kernel sources.
> >>
> >> Including stdbool.h in the kernel is not a style bug, but unsupported.
> >>
> >> > What I want to check on is, would it be acceptable to move stdbool.h
> >> > from include/stdbool.h to sys/sys/stdbool.h (i.e. like errno.h) and
> >> > then include it in the kernel as <sys/stdbool.h>?  That is, is the
> >>
> >> Would be a larger style bug, especially if it were actually used.
> >> Even its spellings of TRUE and FALSE are strange.  Even in userland
> >> stdbool.h is considered so useful that it is never used in src/bin
> >> and is only used a few times on other src/*bin.  src/bin never uses
> >> TRUE of FALSE either.
> >
> > I suspect there is some bias here though due to the fact that there wasn't
> > a standard bool type when most of this code was written. :)  I don't think
> > that means we have to forgo use of the new type now that it is in fact
> > standardized in C99.  I would be happy to have 'bool' available and the
> > lowercase 'true' and 'false' are fine with me.
> 
> In further thinking, there's also a style issue of nested headers.
> FreeBSD expects most types defined in sys/types.h so that it can be
> included first and other files alphabetically.  Using <sys/stdbool.h>
> would require any header with a bool parameter, return code, or struct
> member to include <sys/stdbool.h>.  Alternatively, I could instead put
> the same guards as stdbool.h uses and define bool, true, and false in
> sys/types.h, but only for _KERNEL use (however, this also would create
> issues with any file that is built in both user-space and kernel, and
> unconditionally defining in sys/types.h could break existing buggy
> applications).

Userland apps that #define _KERNEL deserve to be broken and deal with
the fallout accordingly. :)  I think exposing it in the kernel
via <sys/types.h> would be fine.

-- 
John Baldwin