Use of bool / stdbool.h in kernel
mdf at FreeBSD.org
mdf at FreeBSD.org
Sun Dec 4 16:49:09 UTC 2011
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
*sigh*, part of the problem is the buggy way in which C99 added the
bool type. I suppose code could always use the real reserved keyword
_Bool in headers, ugly though it is, and bool in implementation files.
I had a brief look, and for comparison Linux has the typedef in
linux/include/types.h IIRC but does not guard the definition nor did
it define true/false.
More information about the freebsd-arch