From owner-svn-src-projects@FreeBSD.ORG Tue Mar 5 15:30:13 2013 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 18DF040F; Tue, 5 Mar 2013 15:30:13 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA5189A; Tue, 5 Mar 2013 15:30:11 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r25FUAV2055906; Tue, 5 Mar 2013 19:30:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r25FUAiA055905; Tue, 5 Mar 2013 19:30:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 5 Mar 2013 19:30:10 +0400 From: Gleb Smirnoff To: mdf@FreeBSD.org Subject: Re: svn commit: r247710 - projects/calloutng/sys/kern Message-ID: <20130305153010.GL48089@FreeBSD.org> References: <201303031339.r23DdsBU047737@svn.freebsd.org> <201303041521.06557.jhb@freebsd.org> <201303041620.52100.jhb@freebsd.org> <20130305201211.M902@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Davide Italiano , src-committers@freebsd.org, John Baldwin , attilio@freebsd.org, 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 15:30:13 -0000 On Tue, Mar 05, 2013 at 07:25:54AM -0800, mdf@FreeBSD.org wrote: m> On Tue, Mar 5, 2013 at 1:43 AM, Bruce Evans wrote: m> > Why? There is no existing practice for [bool] in the kernel. There is some m> > in the Linux kernel :-). m> m> IMO this is the problem with style always conforming to existing code. m> There is no way to introduce new concepts. m> m> bool may be slightly pessimistic from the standpoint of compiler m> forcing 0/1. However, since C is weakly typed, we "should" all have m> been writing our control statements that take a boolean to evaluate to m> a boolean argument, as implied by the style guideline that '!' is only m> applied to boolean statements. That style recommendation is often not m> followed; e.g. there's plenty of code like if (!error) (I found 762 m> instances in sys/). m> m> To unpack what I said, without a bool type if (error) was style-weird m> since it wasn't a boolean used in a boolean expression, but C was m> "clever" and decided how to do that, instead of requiring the boolean m> expression if (error != 0). style(9) had an example of a proper m> boolean but that form is used less frequently than the shorter C idiom m> of if (error). (17942 instances of if (error) versus 3168 instances m> of the more style(9)-correct if (error != 0)). m> m> Types are there to document things for humans, with a side effect of m> documenting things for the hardware. Efficiency is important but m> rarely king; for example no one went around changing loop counters m> form int to long for 64-bit hardware even though some operations on m> long are faster since they don't need to sign-extend (and possibly m> some operations on long are slower since on x86 the instruction may be m> more bits, and icache is so important. But I doubt the experiment was m> even done). m> m> bool serves the purpose of documenting exactly that something is m> true/false and no other value. bool++ was a lazy way of writing bool m> = true, and suffered from a theoretical problem of overflow when bools m> were ints and not a language-defined type with explicit semantics. m> m> Anyways, my long-winded point was that the C language has evolved. If m> our highest style guide is that we preserve existing style, we will m> never use new language features since they never used to exist. So I m> don't think that the absence of any code examples is a reason to m> forbid code. +1 Thanks for typing the long explanation, Matthew. -- Totus tuus, Glebius.