From owner-freebsd-arch@FreeBSD.ORG Thu Dec 1 15:43:20 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B1D81065670; Thu, 1 Dec 2011 15:43:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C5CAE8FC17; Thu, 1 Dec 2011 15:43:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYAAKif106DaFvO/2dsb2JhbABEhQOVU5EogXIBAQQBIwRSBRYOCgICDRkCWQYTiAemFZF5gTCCPIYegRYEiCiML5Iw X-IronPort-AV: E=Sophos;i="4.71,278,1320642000"; d="scan'208";a="147824628" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 01 Dec 2011 10:43:18 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E0E65B3F99; Thu, 1 Dec 2011 10:43:18 -0500 (EST) Date: Thu, 1 Dec 2011 10:43:18 -0500 (EST) From: Rick Macklem To: John Baldwin Message-ID: <685533129.733983.1322754198902.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201112011012.16891.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Zack Kirsch , mdf@freebsd.org, David Schultz , freebsd-arch@freebsd.org Subject: Re: Use of bool / stdbool.h in kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 15:43:20 -0000 John Baldwin wrote: > On Thursday, December 01, 2011 9:07:18 am Rick Macklem wrote: > > David Schultz wrote: > > > On Wed, Nov 30, 2011, John Baldwin wrote: > > > > On Wednesday, November 30, 2011 12:13:53 am Bruce Evans wrote: > > > > > On Tue, 29 Nov 2011 mdf@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 ? 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. > > > > > > The lowercase 'true' and 'false' are intended to mimic C++, where > > > they are keywords. Regardless of how you prefer to capitalize > > > them, using them instead of 0 and 1 makes the intent much clearer. > > > This is especially true in the kernel, where non-zero could mean > > > true, or it could be an error code. > > > > > > Unfortunately, the "new type" is mostly useless, aside from > > > improving readability. Unlike modern languages, C doesn't > > > consider it a compile-time error to mix up bools and ints. > > > > > If this is added, would the style gods approve of the following: > > > > (A) bool test_func(); > > > > if (test_func()) > > ... > > > > instead of: > > > > (B) int test_func(); > > > > if (test_func() != 0) > > ... > > > > Personally, I prefer the former, but understand that it isn't > > currently style(9) compliant. Being able to do (A) instead of > > (B) would be why I'd like stdbool.h to be added to the kernel, > > if it will be allowed after the change? > > My understanding is that (A) is fine if test_func() is returning an > actual boolean value (so the return value is only true and false). > A case where this isn't really true is when the function returns an > errno as that is returning an int with many values other than just > 0 and 1. Granted, it is a common style violation (I am guilty) to do: > > if (error) > return (error); > Yes, guilty as well. Once I became aware that it was a style(9) violation I've resisted doing it, but barely;-) Thanks for the commments, rick > I also consider it a boolean test to test a single-bit flag in a flags > field: > > if (p->p_flag & P_PROFIL) > > vs. > > if ((p->p_flag & P_PROFIL) != 0) > > If you had a multi-bit field though then I think it is appropriate to > be more > explicit about which values of that field are being tested for. Thus: > > #define FLAGS_SIMPLE 0x00001 > #define FLAGS_FIELD 0x000fe > > if (foo & FLAGS_SIMPLE) > ... > > if ((foo & FLAGS_FIELD) != 0) > ... > > -- > John Baldwin