From owner-svn-src-projects@FreeBSD.ORG Tue Mar 5 13:02:44 2013 Return-Path: Delivered-To: svn-src-projects@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 304B3560; Tue, 5 Mar 2013 13:02:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 71D81CF8; Tue, 5 Mar 2013 13:02:42 +0000 (UTC) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r25D2fQK015076; Wed, 6 Mar 2013 00:02:41 +1100 Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r25D2MT4011870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Mar 2013 00:02:25 +1100 Date: Wed, 6 Mar 2013 00:02:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Hans Petter Selasky Subject: Re: svn commit: r247710 - projects/calloutng/sys/kern In-Reply-To: <5135DFD5.5050708@bitfrost.no> Message-ID: <20130305232805.X1535@besplex.bde.org> References: <201303031339.r23DdsBU047737@svn.freebsd.org> <201303041521.06557.jhb@freebsd.org> <201303041620.52100.jhb@freebsd.org> <20130305201211.M902@besplex.bde.org> <20130305094819.GI48089@FreeBSD.org> <20130305214655.C1224@besplex.bde.org> <5135DFD5.5050708@bitfrost.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=DdhPMYRW c=1 sm=1 a=gRR7UNw4rV0A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=Y4pc3zAY36oA:10 a=QIfvWVCBJqZ7fQjckfEA:9 a=CjuIK1q_8ugA:10 a=X6xPAQGtvaNsGfp-:21 a=-Vp17d4JB-KZqZpi:21 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: Davide Italiano , src-committers@FreeBSD.org, John Baldwin , attilio@FreeBSD.org, Gleb Smirnoff , Bruce Evans , svn-src-projects@FreeBSD.org X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 13:02:44 -0000 On Tue, 5 Mar 2013, Hans Petter Selasky wrote: > On 03/05/13 12:21, Bruce Evans wrote: >> On Tue, 5 Mar 2013, Gleb Smirnoff wrote: >> >>> On Tue, Mar 05, 2013 at 08:43:33PM +1100, Bruce Evans wrote: >>> B> > I think for new code we should prefer C99's bool to boolean_t. >>> B> >>> B> Why? There is no existing practice for this in the kernel. There >>> is some >>> B> in the Linux kernel :-). >>> >>> Why? Because it is standard. What for? To make it more easy for newcomers >>> to start hacking on FreeBSD kernel. >> >> I think you mean "harder". Now the newcomers need to know: >> - the old method, which is used in most places >> - the new method >> - style rules for old, new and mixed methods >> - arcane C99 points like whether bool can be used in bit-fields (I had to >> look this up to check it. It can). >> >> I now see technical reasons to never use bool in kernel or other low-level >> code. It will cause minor pessimizations converting nonzero to true (1) >> at runtime, and for converting bool to register_t when passing parameters >> (bool is 1 byte on x86). To use bool in structs (when not packing it into >> bit-fields), we need to know too much about its size to pack it properly... > > I'm not sure how good you all are at C99. There is a subtle difference I am a language lawyer for C90 and C99 :-). I don't know much about C11 or C++. > between bool (compiler type) and boolean_t (typedef'ed), and that is when > assigning an non-bool value. This is probably bad style, but I just want to > show you the difference: > > #include > #include > > typedef int boolean_t; > > int main() > { > bool var1; > var1 = 3; > printf("%d\n", var1); > > boolean_t var2; > var2 = 3; > printf("%d\n", var2); > > return (0); > } > > If defined correctly, var1 should contain a value of "1", and var2 should > contain a value of "3". Yes, this is what I meant by the bool version being slower since it needs conversions to translate 3 to 1. Here the values are constant so the compiler can do the conversions at compile time so as to not be slower, but in general there will be some conversions at runtime. Also, printf() is variadic, so bools cannot be passed to it. The bool undergoes the default promotions. Again I fail my language lawyer's exam and have to look up what these promotions are. _Bool has rank < char, so it promotes to int and thus your %d format is correct. > Now if for some reason someone like possibly some > Linux guys do, use booleans for counting, you will have an instant error :-) :-). Both gcc and clang generate a move of 1 to `var' for the counting expression `var++' on `_Bool var'. I would prefer an error. I'd better take bools off the language lawyer's exam so that I pass :-). POLA requires C99 to not specify a complete set of operations for nonsensical operations on bools. So apparently, this var++ is just evaluated as an integer expression with promotions from and to bool. var starts as 0 or 1 and so var + 1 is the integer 1 or 2. Then assigning var + 1 back to var gives the boolean 1. Similarly, var += INT_MAX gives either (bool)INT_MAX = 1, or undefined behaviour so it can give boolean 1 in all cases. Similarly var += UINT_MAX gives either (bool)UINT_MAX = 1, or defined behaviour (bool)0 = 0. clang optimizes the former to 1 and the latter to !!var (xor with 1), but gcc evaluates them at runtime. > I'm not saying we should take their example, but anyhow, be warned about the > difference between bool and boolean_t! Bruce